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Az újdonság varázsa 


A Windows 2003 rejtett meglepetései 


Akit hidegenhagynak a szerkeszthető X.509 sablonok, a WMI-filterek, az Active Directory Application 
Partition és a többi , marhaság", az ne tanuljon. De készüljön fel néhány váratlan kudarcélményre, 
mert ezeken kívül egy-két bit még átbillent, mire 2000-ből 2003-ba jutottunk. A legegyszerűbb 


feladatok is okozhatnak meglepetéseket! 


Akár egy könyvtár megosztása is megoldhatatlan rejtély elé 
állíthat bennünket, ha (vakon) sikerül eltalálnunk egy olyan 
pontot az operációs rendszerben, ami már nem úgy működik. 
Egyszerű feladat: a munkaállomásokon futó víruskeresők 
számára kell készítenünk az egyik Windows 2003 kiszolgá- 
lón egy megosztott könyvtárat, hogy onnan töltsék le a írissí- 
téseiket. 

Fogjuk a könyvtárat, jobbklikk, megosztás, beírjuk a megosz- 
tás nevét és OK. Ennek mennie kell, mivel a megosztásokon a 
bántatlan, alapértelmezett jogosultság — mint tudjuk — 
Everyone -5 Full Control. 

Rosszul tudjuk. A biztonságos üzemeltetés érdekében ugyanis 
pontosan 2003 február 17 óta az alapértelmezett megosztás- 
jog: Everyone -5 Read! 

Ezt a ,hibát" viszonylag könnyen orvosolhatjuk: jobbklikk, 
Permissions, és engedélyezzük a Change (változtatás) jogot is. 
A víruskeresőink azonban csak nem férnek hozzá a fírissítési 
adatbázisaikhoz. Most mit tegyünk? Ez már fogósabb problé- 
ma, tekintettel arra, hogy semelyik bátortalan kísérletünk sem 
sikerül. Nem elég neki a Full Control sem. Itt bizony valami- 
lyen kompatibilitási galibába futottunk! 

Szakember legyen a talpán, aki ezt a problémát anélkül képes 
megoldani, hogy tudná: alapvetően megváltozott az Everyone 
csoport! 2003 előtt igaz volt az alábbi képlet: 





A redmondi dizájnerek úgy gondolták, hogy aki névtelen kap- 
csolatot nem akar engedélyezni, majd ügyesen áttér az NT4 
SP3-ban bevezetett Authenticated Users csoport használatára. 
A felmérések tanúsága szerint ezt a lépést a rendszergazdák 0 
(nulla) százaléka tette meg. Mivel azonban Bill úgy döntött, a 
Windows lesz a világ legbiztonságosabb operációs rendszere, 
a lusta rendszergazdák háta mögött cselt forralt, és kivette az 
Everyone csoportból a névteleneket. Tehát ma így fest az 
egyenlet: 


Ez a , hiba" oka. A SYSTEM fiók alatt futó víruskeresők névte- 
len felhasználónak számítanak. Ennek elhárítása azonban 
vagy nem egyszerű (NTLM-világ), vagy nem biztonságos 
(GPO), vagy nem ismert (Kerberos). Lássuk az eseteket sor- 
jában. 


tech.net S At KT 4 § w i 


A A nem egyszerű módszerre NTA alatt van szükség, mert 
ha meg szeretnénk szüntetni a víruskereső anonimitá- 
sát, bizony minden gépen át kell állítanunk a szolgálta- 
tást, hogy ne SYSTEM, hanem valamilyen valós felhasz- 
náló nevében fusson. 

A A nem biztonságos megoldás nem más, mint az 
Everyone csoport visszakapcsolása 2000-kompatibilis 
üzemmódba. Ehhez tartományi csoportházirendet 
használhatunk, így egy laza mozdulattal akár az összes 
Windows 2003-on rést üthetünk a pajzson. Anonimusz 
jöhet. 

A A nem ismert módszer ott használható, ahol a munka- 
állomások Kerberos autentikációt használnak. Ebben 
az esetben beállíthatjuk, hogy a névtelennek számító 
SYSTEM fiók helyett a munkaállomás szolgáltatásai a 
számítógépfiókot (Computer Account) használják 
önazonosításra (például egy MASINA nevű gép esetén 
a bejelentkezési név MASINA$ lesz). Ezt a címtárban 
lévő számítógépen állíthatjuk be. Jobbklikk, tulajdonsá- 
gok, Trust this computer for delegation. 


Ezt a rövid kis példát ízelítőnek szántam. Miközben a Win- 
dows 2003-ban bolyongtam, rengeteg ilyen apróságra buk- 
kantam. Például: 

A A GPO-ban átnevezték a Log On Locally jogot Allow 
Log On Locallyra, hogy nehogy azonnal megtaláljuk. 
Cserében viszont kizárták annak lehetőségét, hogy ki- 
zárjuk magunkat a tartományból: ha másnak nem is, az 
Administratorsnak mindenképpen bent kell lennie a lis- 
tában, enélkül nem lehet leokézni. 

A A DHCP-kiszolgálón suttyomban megjelent egy új op- 
ció, a 249-es. Ennek hasznlatáról lásd a negyedik olda- 
lon kezdődő cikkemet. 

A Az RRAS-ban már nem csak registry hekkeléssel lehet 
rávenni az LZTP/IPSec párost, hogy felejtse el a tanúsít- 
ványalapú azonosítást, hanem térjen át preshared keyre 
(közös titok) 


A többit majd szóban, a tanfolyamokon. 


4 Fóti Marcell 
marcellfönetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 
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172.16.0.100 172.16.0.254 
R1: L E Internet 
68.68.68.68 


komámasszony, hol az ajtó ee 


Enyhén összetett hálózat útválasztásának reestli 

AG ús a. Munkaállomás 

többféle megoldása 172.16.0.18 
Talán nem ritka az a hálózatkialakítási forma, amikor a munkaállomásoknak egyszerre kétfelé kell ,elhagyniuk" a tett színhe- 
lyét, azaz két hálózati kijárat (gateway) használata között kell dönteniük. Vajon elég intelligensek ehhez, vagy (rossz kijárat 
használata miatt) mindenképpen duplázott hálózati forgalommal kell számolnunk? 
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TESANSTSENTETTAT 8 Mi történik, ha hiba esetén egyedül van egy AD 
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B )zzkzrn Esar controller? 
]sátogrie 
e Rémálom a szerverszobában: elszállt az Active Directory, ráadásul mindez egy 
ésava 


SBS 2000 szerveren... Mentés, visszaállítás és minden ami mögötte van! 


AS sezztgzése 5. oldal 





Gyógyszeresdoboz II... SS 
Windows 2000 Server Resource Kit frzredajátrak 


A Network Management Tools II., azaz a sorozat előző részében taglalt, felhasználók- 
kal, csoportokkal és megosztásokkal kapcsolatos eszközök átvilágítása után, most 
tekintsünk bele egy másik világba. 





FF Disable the selected scopes on lócal machine betora export 
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ület ma Megállás nélkül 
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TA E 99,99999-os rendelkezésreállás Windows 
Di. 7 9 ú8 sző jő 
sz kö si 8 operációs rendszerrel? 
re A 
A cél az ,ötkilences" rendelkezésre-állás. Évente 5 perc leállás. 
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táncolunk, clustert építünk és fürtözünk? Ide ez már nem elég. Ez 
már egy más kategória, itt a fürt hamar elvérzik. Ide Stratus kell! 


e z 4 a 
A DALP rejtett szépségei — I. eeedee eme ds e [e 

Egy végső lendülettel megbirkózunk a DHCP utolsó nagy fogalomkörével, 
vagyis az osztályokkal és opciókkal. A cikksorozat második részében már 
megemlítettük a legfontosabbakat, de túlságosan nem merültünk el a részle- 
tekben. Most viszont épp ezt fogjuk tenni, hogy megértsük, milyen eszkö- 
zeink vannak az ügyfelek finomhangolására, s egyáltalán: mi mindenre ké- 
pes a DHCP... 
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e a a Internet Information Services 6.0, I. rész ÚT! 


2 LETE 1 Levelező-szolgáltatások a Windows Server 
G.A senvent 2003-ban: a POP3 


7 H SERVER2003 

Régóta vártunk arra, hogy a levelek fogadásáért és kiküldéséért felelős 
SMTP-szolgáltatás mellett a felhasználók postafiókját és az ahhoz való hozzá- 
férést biztosító POP3 is megjelenjen a palettán. A Windows Server 2003-ban 
végre itt van — kicsit butuska, kicsit egyszerű, de a mienk :-) 





16 nalr 
! 11 
] 

sr 


Tanúsítvánukiadók a Iindotusban  eeeeeszere a 


Mi van egy tanúsítványban? 





Cikkünk következő részében először az X.509 digitális tanúsítványok mélyreható 
boncolgatására kerül sor, majd visszatérünk a Windows Server 2003, Enterprise 
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S IPSec NAT Traversal — az IPSec új 
üzemmódja 

A Windows 2000-ben bevezetett IPSec protokoll egyik nagy 
hátránya volt, hogy az általa titkosított csatorna nem volt képes áthaladni hálózati címfordító (NAT — 
Network Address Translation) eszközökön. A Windows 2003 már tartalmazza, Windows 2000-hez és 
XP-hez pedig letölthető azt a bővítés, ami megoldja ezt a problémát is. 


r e 
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§-a NAT-T: IPSzc NAT-on keresztül 


UDP 4500 c- 


UDP x00000£ c- UDP 4500 


Biztonságos aláíráskezelő alkalmazás [BALE] készítése ID. 


] 

Adatok és komponensek 

] A hosszúra nyúlt bevezetés után végre eljutottunk a gyakorló informatikus kollégák számára min- 

] den bizonnyal kedvesebb témákhoz. Jelen részben az aláíráskezelő alkalmazás által használt ada- 
tokról, az aláíráslétrehozó alkalmazás ezeket hasznosító komponenseiről, valamint az alkalmazás- 
sal szemben támasztott követelményekről lesz szó. Egyben folytatódik a mindennek nevet adunk- 

szakkör, ami most ér igazi csúcspontjára, hiszen most egyes fogalmaknak új elnevezést adunk. Tessék ka- 
paszkodni, mert aki eddig netán értette, az most könnyen elveszítheti a fonalat. 


30. oldal 


Elliptikus görbe kriptorendszerek II. rész 
Elliptic Curve Cryptography - algoritmusok és a gyakorlat 


Egy jó ideje egyre több helyen találkozhatunk az ECC betűhármassal, mint egy kriptorendszer 
jelölésével. A cikk első részében áttekintettük e viszonylag fiatal kriptorendszer elvi alapjait, most 
jöjjön néhány gyakorlati példa és algoritmus! 


j6. oldal 
Nbjektumorientált alkalmazásfejlesztés 


ElsőOsztályom ——() Az UML 
e. 


SÖKE am — Sok szó esett már az UML-ről, és talán még mindig vannak, akik számára 
attribútum ég) nem egyértelmű, mit is takar ez a három betű tulajdonképpen. Számukra 
szeretnék egy kis segítséget nyújtani, hogy tisztább legyen a kép, és ne 
rémüljenek meg, ha egy osztálydiagram feltűnik valahol. 
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. Enyhén összetett hálózat útválasztásának többféle megoldása / Windows 


hol az ajtó? 


komámasszony, 


73 


komámasszony, hol az ajtó" 


Enyhén összetett hálózat útválasztásának 
többféle megoldása 


Talán nem ritka az a hálózatkialakítási forma, amikor a munkaállomásoknak egyszerre kétfelé kell , el- 
hagyniuk" a tett színhelyét, azaz két hálózati kijárat (gateway) használata között kell dönteniük. Vajon 
elég intelligensek ehhez, vagy (rossz kijárat használata miatt) mindenképpen duplázott hálózati forga- 


lommal kell számolnunk? 


Elsőként vázolnám a problémát, vagyis felrajzolom azt a hálóza- 
tot, amelyben a munkaállomásnak el kell döntenie, vajon a ren- 
delkezésre álló routerek közül adott esetben melyiket válassza? 






Adatbázis 
[E] 
— 
E] 
CET 
172.16.0.100 —— 172.16.0.254 an 
(RT: 12; (Internet 
10.10.10.10 68.68.68.68. 1 


I 


Munkaállomás 
172.16.0.13 
E Egy tipikus, adatközponttal és Internetkapcsolattal 
rendelkező hálózat felépítése 


Az ábra egyszerűsége miatt talán magyarázatra szorul, hogy 
hol itt a gond? Mivel a munkaállomás gazdája bizonyosan 
szeretne Internetezni, beállítjuk az R2-vel jelölt útválasztót, 
mint alapértelmezett átjárót (Default Gateway). Az adatköz- 
pontban található adatbázis eléréséhez pedig R1-et is beállít- 
juk alapértelmezett átjáróként. A TCP/IP tulajdonságok, 
Advanced fülén lehet felvenni a sokadik átjárót: 


Default gateways: 
! 


I Gateway I Metric 
! 172.16.0.254 Automatic 
172.16.0.100 Automatic 


Add... Remove 


B Egynél több alapértelmezett átjáró. Bizarr ötlet? 


Egy sima IPCONFIG parancs kiadásával le is ellenőrizhetjük, 
hogy mit műveltünk: 


EE 





C:Wocuments and SettingsMarci2Zipconfig 


Windows IP Configuration 


Ethernet adapter Local Area Connection: 


Connection-specific DNS Suffix § 
ay. rá vat as fs Jót tat 26 GAEL 





a? BITES a zs s. 

Subnet Mask . . . . . : 255.255.0.0 

Default Gateway . . . :[172.16.0.254 
172.16.9.100 














A két átjáró azt igazolja, hogy a dolog működik... De! 


Ha most a munkaállomásról hálózati forgalmat indítunk 
mindkét kritikus irányba, Network Monitorral láthatjuk, hogy 
a gép nem veszi figyelembe a második átjárót. Nem nyert! 


Dead Gateway Detection 


Első körön sikerült belefutnunk a TCP/IP implementáció egyik 
gyakran félreértett tulajdonságába. Nevezetesen abba, hogy 
ha egynél több alapértelmezett átjárót adunk meg, akkor a 
Windows az elérendő cél függvényében majd okosan hol 
egyiket, hol másikat fogja használni. Hogy ez biztosan nem 
így van, sőt el sem képzelhető, hogy így működjön, az úgyne- 
vezett útvonaltábla (routing table) szolgál bizonyítékkal. Néz- 
zük meg (ROUTE PRINT), mit is tartalmaz egy ilyen 
duplaátjárós gép úttáblája! 


EZETETI CE 


: Wocuments and SettingstMMarci2route print 










letive Routes 





letwork Destination Netmask Gatewa Interface 
0 0 0.6.0.0 6.0.100 172.16.0.13 

0 09.0.0.0 6.0 172.16.0.13 

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 
172.16.0.0 255.255.0.0 172.16.0.13 172.16.0.13 
172.16.0.13. 255.255.255.259 127.0. 127.0.0.1 


B A két default gateway megjelenése az útvonaltáblában 


A ,hiba" oka világosan leolvasható: a Default Gateway 
csupanullás bejegyzései azt jelentik, hogy minden olyan cso- 
magot, amiről nem tudjuk halál pontosan eldönteni, hogy ho- 
va menjen, dobjuk csak neki. 

Csakhogy mindkét DG ugyanígy került be a táblába, egyik 
sorban sincs egy fikarcnyi ,intelligencia" sem, így nem lehet 
eldönteni, hogy melyik vezet az Internetre, és melyik az adat- 
központba! 

Az ábráról egyébként lemaradt mégegy paraméter: a metric. 
Ezt azt határozza meg, hogy az egyes útvonalakat milyen 
prioritás szerint használja a munkaállomás. Nos, ez sem visz 
előre, mivel mindkét DG-nél a metric-30. Elvileg így egyenlő 
eséllyel kellene használnia mindkettőt (terhelésmegosztás, 
load balance), de mégcsak nem is ez történik. Hanem a 
következő: amíg az első DG él és virul, a másodikat nem ve- 
szi használatba. Ennek a működésnek a hivatalos neve: Dead 
Gateway Detection. Nem mellesleg: ha egynél több DNS-ki- 
szolgálót állítunk be, azok közül is mindaddig a legelsőt hasz- 
nálja, amíg az meg nem döglik. 

Jelenleg tehát mivel a 172.16.0.254-es átjáró van elöl, a mun- 
kaállomás minden kimenő csomagot R2-nek küld, amit az 









szétválogat, és az adatközpontba tartó csomagokat egyesével 
átküldi R1-nek. Ezt szaknyelven úgy nevezik: duplázott háló- 
zati forgalom! 


Megoldás I. - az útvonaltábla kézi módosítása 


Ha sikerülne felokosítanunk az útvonaltáblát, és kiderülne, 
hogy pontosan mely címekre menő csomagok érdekében ér- 
demes használni egyik vagy másik routert, sokkal előrébb len- 
nénk. Mivel az összes Internetes cím megadása gyakorlatilag 
lehetetlen, jobban járnánk, ha az adatközpont címeire taníta- 
nánk meg a kis buta munkaállomást. Ehhez először is vegyük 
ki a TCP/IP-beállítások közül a második átjárót, majd a 
következő bűvös paranccsal adjuk meg, hogy minden 10-es 
címre menő csomagot R1-re kell továbbítani: 





Ezután az útválasztótábla így néz ki (csak a lényeget emel- 
tem ki): 


Network Destination Netmask Gateway Interface 
.0.0. 0.0.0.0 172.16.0.254 172.16.0.13 
10.0.0.0 55.0.0.0 172.16.6.100 172.16.0.13 


B Egy konkrét hálózat (10.0.0.0) szerepel az útvonaltáb- 
lában 


És ezzel már jól fog működni a munkaállomás: az adatköz- 
pontba menő csomagokat R1-nek, az Internetre menőket R2 
felé továbbítja. 

Nincs is más hátra, mint végigmenni a hálózaton, és mind az 
534 munkaállomáson kiadni a route add parancsot. Természe- 
tesen /P kapcsolóval, hogy a hatás maradandó legyen 
(persistent route). 

Nem lehetne ezt másképp? Központosítva? Automatizálva? 
De, lehetne, mégpedig többféle módon is. 


Megoldás II. - az útvonaltábla módosítása DHCP-vel 


A cikkben vázolt útválasztási probléma mintegy hat éve szúrja 
a szememet. Hat évvel ezelőtt még nem volt rá gusztusos, au- 
tomatikus megoldás, mert sem a most említendő DHCP, sem a 
III. megoldás nem működött NT4-gyel. Gusztustalan persze 
volt: egy route add parancsot tartalmazó login script. Fuj. 
Pedig már akkor kiszúrtam magamnak, hogy a DHCP opciók 
között virít egy 33-as sorszámú, Static Route nevű csoda, amit 
pont nekünk találtak ki. Mi más lehet a static route, mint egy 
kézi" bejegyzés a DHCP-ügyfelek útvonaltáblájába? 

A 33-as pont az, de több sebből vérzik. Az első seb abból fa- 
kad, hogy (anno 1996) a DHCP-ügyfél Windows nem veszi 
figyelembe, hiába állítjuk be. Csak és kizárólag azt a 6-7 op- 
ciót fogadja el, amit jelen számunk DHCP cikkében is olvas- 
hatnak. 

De nagyot változott a világ a múlt század óta, és ma már ezt 
is elfogadják a Windowsok (Windows 2000-től kezdődően). 
Viszont van egy második seb is: a 33-as opció CIDR előtti. (Az 
1993-as Classless Interdomain Routing szabvány az IP-cím 
pocsékolás megakadályozására engedélyezi, hogy egy IP- 
címtartományt tetszőleges subnet maskkal ripityára aprítsunk.) 
A CIDR-előttiség azt jelenti, hogy a 33-as opciónál nem lehet 
subnet maskot megadni az útvonal megadásakor, hanem az 
IP-cím osztályából (A, B, C) következő maszkot rendeli hozzá 
a rendszer. Ez ma már nem számít korszerűnek, mondhatni 
hajítófát sem ér. 

Csakhogy ma 2003-at írunk. A technológia fejlettsége trillió- 
szorosa a három évvel ezelőttinek, ezért vettem a fáradságot, 
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és belekukkantottam a Windows 2003 DHCP- 
kiszolgálójába, vajon történ-e ezen a téren változás? 
Igen, igen, igen! 

Született egy új opció (a 249-es), amit PONT nekünk 
találtak ki! Végre megoldható a munkaállomások út- 
vonaltáblájának korrekt módosítása! Milyen kár, hogy erre ma 
már semmi szükség! Hogy miért? Mert a III. megoldás a nyerő. 





Megoldás III. Öntanuló hálózat 


Elgondolkodtak-e már azon, milyen jó is lenne egy olyan há- 
lózat, amely felfedezi a saját problémáit, és segít magán? Ha 
itt még nem is tartunk, de a duplázott hálózati forgalom ellen 
van automatikus eljárás. Ez pedig a munkaállomások , távtaní- 
tása" a routerek révén. 

Dobd ki azt a routert, ami nem észleli a duplázott hálózati for- 
galmat, és nem szól vissza a feladónak, hogy ,hé öcsi, rossz 
ajtón kopogtatsz!". 

Persze ettől még nem javul meg egy csapásra minden, mert a 
munkaállomás nem köteles figyelembe venni a baráti figyel- 
meztetést, bár a Windowsok NT4 SP3 óta figyelembe veszik, 
és hálásan át is vezetik útvonaltáblájukat — pont úgy, ahogy az 
imént ezt puszta kézzel tettük. 

Mi is ez a csodaüzenet, ami ilyen fantasztikus hatást vált ki a 
gépekből? Nem fogják elhinni: ICMP (Internet Control 
Message Protocol). Ez ugyanaz a protokoll, mint amit a PING 
használ, csak annak egy másik ága, az ICMP Redirect. 

A Redirect , parancs" segítségével az erre felkészített routerek 
utasítgathatják klientúrájukat, hogy melyik csomagot merre 
dobálják. A Windowsok pedig engedelmeskednek. Talán túl- 
ságosan is engedelmesek. Mindegy nekik, ki küldte a Redirect 
parancsot, ők átállítják útvonaltáblájukat. Egy-két jólirányzott 
ICPM Redirect üzenettel pillanatok alatt le lehet szakítani egy- 
egy alhálózatot a hálózat többi részéről. 

Ennek elkerülésére jelenleg egyetlen módszer ismeretes: a 
Network Monitor teljes verziójához adott Monitor Control 
Tool. Ez az eszköz különböző kellemetlen és nem várt háló- 
zati jelenségek felbukkanását figyeli, és riadalmat kelt, ha gya- 
nús eseményt észlel. (Nem, nem küld semmit. Amikor ez ké- 
szült, még nem volt divat az email-értesítés.) 

Egyébként bámulatosan egyszerű eszköz, csak kettőt kattin- 
tunk a kiválasztott ellenőrön, és ő a parancs megadása után 
azonnal szolgálatba lép: 






Tetten ei 





In the text box to the left, 
enter the IP addresses of 
trusted servers. 





2 ICMP Redirect monitor a Monitor Control Toolban 
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Mi történik, ha hiba esetén egyedül van 
egy AD controller? 


Rémálom a szerverszobában: elszállt az Active Directory, ráadásul mindez egy SBS 2000 szerveren... 


Mentés, visszaállítás és minden ami mögötte van! 


Az egész úgy kezdődött, hogy hétfő reggel olyan állapot foga- 
dott munkahelyemen, ahogyan azt a legkevésbé vártam vol- 
na. Ahogy beléptem, megláttam, hogy a szerverszoba ajtaja 
nyitva van és az a valaki, aki kinyitotta nincs bent, hanem — 
feltehetőleg tesztelés céljából — elment megnézni, hogy jó lett- 
e... Mármint annak a cselekvéssorozatnak a hatása amit az 
előbb megpróbált az egyik szerveren véghezvinni. Nekem, 
mint a hálózat rendszergazdájának ilyenkor összeugrik a 
gyomrom, és a probléma végleges megoldásáig úgy is marad. 
Kisvártatva egyik kedves kollégám jött szembe azzal, hogy 
nem működik a weboldal, amit többek között az érintett szer- 
ver szolgáltat. 

Ekkor rövid kattintgatás után kiderült a legrosszabb: a Small 
Business Server 2000 teljesen felmondta a szolgálatot. Sőt, a 
kezdeti legjobb megoldás — a restart — csak rontott a helyze- 
ten, mert ezután még kétszer magától újraindult. Igaz harma- 
dikra összeszedte magát, és a rajta levő Exchange adatbázisok 
is felmountolódtak, de nem volt tökéletes a működése. Ennek 
a következő jelei voltak: bármilyen Explorer indítása a teljes 
task lehalásához vezetett, a desktop-explorer minden kísérlet- 
re azonnal újraindult. Ám a legrosszabb az volt, hogy időn- 
ként a következő üzenet jelent meg egy kis figyelmeztető ab- 
lakban: , Memory could not be written"(!) Ekkor még vicces 
kedvünkben voltunk, így elkezdtünk találgatni, hogy vajon 
miféle űrtevékenység folytán alakult át a RAM memória ROM 
típusúvá... ahogyan azt a fenti üzenetből elsőre gondoltuk. 
De a viccelődés hamar abbamaradt, amikor láttuk, hogy mek- 
kora a baj. Technikailag a szerver egy igen erős vas (DELL 
Power Edge 6400, dual Xeon, 2 GB RAM, 18 GB RAIDI HDD 
System és 70 GB RAID5 HDD Data) a gyártó cég egyik 
kiemelkedő, csúcsminőségű modellje. De mégis, a hibaüze- 
netből arra gondoltunk, hogy hardverhibáról van szó, hiszen 
világosan megmondta, hogy nem tudja írni a memóriát. 
Mindezek mellett azt is vizsgáltam, hogy mi az, ami még nem 
működik. Elérhetetlen volt az IIS metabase, így nem szolgál- 
tatta a weboldalakat, illetve képtelen voltam bármit csinálni a 
konzolon, mert minden fél percben elszállt az Explorer. Ha- 
mar kiderült, hogy ez így nem maradhat, hiszen minden tize- 
dik másodpercben előállt a fentebb említett memóriaírási hi- 
baüzenet is. 

Úgy döntöttünk, hogy kihívjuk a hivatalos szervizt, kérve egy 
új memória modult, mivel még ekkor teljesen biztosak vol- 
tunk abban, hogy annak kicserélésével a probléma megoldó- 
dik majd. Ha így lett volna az én cikkem is csak eddig tartott 
volna, de nem így történt... 

A másik modullal is ugyanígy viselkedett, és produkálta az 
auto-restartot is, ami szerver esetében igen-igen zavaró. Hi- 
szen nem tudhattuk, hogy hány restart után indul el végre, és 


miért van, hogy néha nincs restart indulás előtt, néha meg ket- 
tő is van. Gondolom, nem vagyok egyedül azzal az érzéssel, 
hogy nem szeretem a számítástechnika világában az egyesek 
és nullák mellett olykor előforduló másfelet! De akármilyen 
hihetetlen is, ez a problémakör egyidős a szakmával... 


Hát ez bizony nem hardverhiba! 


Miután a memóriacsere nem segített, kitaláltuk, hogy a szer- 
verben található ötféle BIOS és egyéb Firmware frissítése után 
egy tartalék HDD-re felteszünk egy szűz Windows 2000 szer- 
vert tesztelés céljából. Mondanom sem kell, hogy azzal sem- 
mi baja nem volt a memóriának, és 
minden tökéletesen működött. Itt kel- 
lett elfogadnunk azt a szomorú tényt, 
hogy a hiba szofítver-eredetű. Nem ad- 
tuk ám fel ilyen könnyen, mert még ki- 
próbáltuk azt is, hogy a diszkeket egy 
pontosan ugyanilyen szerverbe betéve 
elindítottuk a rendszert. Sajnos 
ugyanúgy viselkedett, mint a másik 


Visszaállítani egy AD 
controllert ha 


egyedül volt és 


minden fontos vassal, azaz minden addig előforduló 
. hibajelenség előjött itt is. 
adattal csak ő Ennél a pontnál kerültek tanácskozá- 


saink előterébe a mentések. Egy évvel 
ezelőtt, amikor átadtam a szervert, a 
mentést úgy terveztem, hogy DAT ka- 
zettára (napi cserélgetéssel) egy héten 
öt mentés készül. Mivel a használt 
DAT mérete lehetővé tette, igencsak 
bőkezűen bántam a menteni valóval. 
Az alkalmazott szoftver a Veritas 
Backup Exec 8.6-os terméke, kiegé- 


rendelkezett... Nem 
lehetetlen, de 


nem is egyszerű! 


szítve a hozzávaló Exchange 2000 Agenttel. Ezzel nagyon jól 


kézbentartott időzített mentéseket lehet készíteni és én szán- 
dékosan úgy állítottam be, hogy a lehető legtöbbet mentsen 
minden nap. Így redundáns információ is volt bőven, de 
megérte! Készült sima online adatbázisszintű mentés az 
Exchange-ről, illetve rögtön utána individuális mailboxon- 
kénti mentés is. Az egész C (System) drive, illetve a System 
State is minden nap a kazettára került. Hogy ez miért fontos, 
arra most nem térek ki, mert az [sbsreskit] címen elérhető SBS 
2000 Resource Kit Documentation részletesen foglalkozik a 
biztonságos mentés megtervezésével. 

De egy hibát azért elkövettem, mégpedig azt, hogy nem volt 
a mentési tervben egy havi és mondjuk egy háromhavi men- 
tési kazetta. Így minden hétfőn felülíródott a múlt hétfői, ked- 
den az előző keddi anyag, és így tovább. Sokszor volt adat- 
visszaállítási kérés a felhasználóktól, és erre ez a módszer tö- 





kéletesen megfelelt. De nem most! Ugyanis a hiba 
régebbi eredetű volt, mint egy hét, így a mentés összes adat- 
hordozója javában tartalmazta a bugot, mire észrevettem, 
hogy baj van. Az adatokkal, fájlokkal semmi gond nem volt, 
de az Active Directory csúnyán megsérült, így a System State 
backup is ezt az állapotot rögzítette a kazettára. Mivel a 
szerver egy SBS 2000 volt, a probléma is halmozottan jelent- 
kezett. 


Az Active Directory-tervezés és az SBS... 


Ugye azt mindnyájan tudjuk, hogy nem jó - és a Microsoft ál- 
tal kifejezetten ellenjavallt — ha egy AD controller egyedül 
van. Továbbá az sem jó, ha a GC van egymagában és még 
ráadásul Exchange szerver is van rajta. Erre mindezek ismere- 
tében kiadnak egy terméket, ami nem is működik máshogy! 
Ha akarjuk sem! Az SBS egyedül van, és úgy is marad. , Ha baj 
van, javítsd meg magad!" 

Az egyetlen általa létrehozott domainben ő egyedül a kiski- 
rály, és nem tűr meg maga mellett semmilyen más kiszolgálót 
sem. ,Nagy baj lesz ha..." típusú ügyvédi, jogi szövegekkel 
teleírt ablakok tömkelegét szórta rám még attól is, amikor a 
hálózatban található másik domain DHCP szerverével került 
összetűzésbe. Ezek után persze csakis a mentésben bízhat a 
szegény adminisztrátor, nem úgy, mint egy ,rendes" domain 
esetében, ahol legalább kettő tartományvezérlő tartja az AD 
adatbázist. 

Persze mielőtt az ember elkezd egy teljes visszaállítást, meg- 
próbál mindent, amit csak tehet. Mert elölről kezdeni egy év- 
nyi munka után - brrr... ez szörnyen hangzik. Itt kezdődtek az 
álmatlan éjszakák. 

Eredeti SBS W2K CD-ről indított Recovery-Install, System File 
Checker és társai. Persze közben egy 50 fős csapat — a felhasz- 
nálói tábor — kényszeredett nyári szabadságon van, mert a mai 
informatikával telezsúfolt világunkban már szinte egy kávét 
sem főzünk meg, ha nem jó a szerver. Tudom, hogy az a sors- 
társam, aki látott már tétlen felhasználót az irodában téblábol- 
ni, mert nem tudja kinyitni az e-maileket, az tudja, hogy mi- 
ről beszélek. Én meg persze ilyenkor megteszek mindent, 
hogy a lehető legrövidebb idő alatt elhárítsam a bajt: éjszakai 
próbálkozások, hogy esetleg reggelre már jó legyen, stb., stb. 
Nem először derítettem fényt a szervezetem végső határaira, 
ugyanis három nap alvás nélkül — és utána belázasodom. Ez 
van, ennyit tud földi porhüvelyem. A szerver persze soha nem 
alszik, nem fárad el, és addig nem hagy nyugodni, amíg meg 
nem javítom. Fontos megjegyezni, hogy ennek semmi de sem- 
mi értelme. Tiszta fejjel, kipihenten sokkal hatékonyabban le- 
het dolgozni, és kisebb az újabb hibák elkövetésének veszé- 
lye is. ,De ha egyszer annyira jó lenne most gyorsan megol- 
dani, és reggelre már működne is"... Ugye ismerős? Ördögi 
kör! Nem is ez vezetett sikerre. Mert persze az volt a végén, 
azért is írom ezt a cikket, mert elhatároztam, hogy ha sikerül 
végül helyrehozni ezt a szervert, megosztom a tech.net olva- 
sóival az odáig vezető út minden örömét és bánatát. 

A Directory Services Restore módban indított szerverre vissza- 
tettem az egyik legutolsó kazettáról a System State-et illetve a 
teljes rendszert és vártam, hogy megjavuljon. De ehelyett 
minden fontos service arról számolt be, hogy nem tud vala- 
miért elindulni. Egyik ezért, a másik azért, de a lényeg, hogy 
szinte semmi sem ment. Ezután jött a repair a gyári CD-ről. 
Ekkor viszont az auto-restart vált folyamatossá mindig, bárme- 
lyik napi kazettával próbálkoztam is. (Vegyük észre, hogy itt 
minden esetben egy teljes installról van szó, amit ,elszúrtam" 
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Repairrel! Ennyi időt nem szabad ilyesmivel eltölte- 
ni, mert az ember az idegei épségével játszik köz- 
ben!) Egyszer kínomban megvártam, amíg egymás- 
után tízszer újraindult, hátha mégis megjön az esze 
közben. Örök tanulság: egy ilyen viselkedésű szerver akkor 
sem lehet jó, ha annak látszik. Ha el is indult volna, akkor sem 
hihettem volna róla mást, mint hogy véres a torka, és úgyis va- 
lami nagyon súlyos gondja van. Tudni kell eldönteni, hogy 
honnantól van reinstallról szó! (Többnyire jóval hamarabb, 
mintsem ahogy azt bevalljuk magunknak.) 


Jöhet a reinstall! 


Elfogadott tény, hogy az a tiszta, ,tuti" megoldás, ha Íriss 
install után visszahozzuk az adatokat a mentésből, és megy 
minden tovább! Sajnos viszont a mentés nem volt teljesen 
használható — pontosan a legfontosabb, az Active Directory 
része nem. 
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E Ha van jó System State backup, az sokat segíthet. Ha 
nincs, jöhet a manuális javítgatás... 


Szerencsére, amikor ezer próbából egyszer nagy nehezen, de 
elindult a szerver, a felhasználók be tudtak lépni. Igaz, semmi 
mást nem tudtak csinálni, mert semmi más nem működött, de 
ez mégis azt mutatta, hogy a csoportok és a userek még meg- 
vannak! 

Így hát — még mielőtt teljesen megváltam volna a régi felállás- 
tól és AD-tól — készítettem egy-egy teljes dumpot az LDIFDE 
és a CSVDE eszközök segítségével. 
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Illetve, 

e:Ma 3 ZSZ, SS EZE ze ar 1 
Az említett parancssori eszközökről röviden annyit, hogy az 
AD szöveges dumpjához, szerkesztéséhez, export és import 
operációkhoz használhatjuk őket. A régi villamosos viccel él- 
ve különbség kettőjük között az, hogy az LDIFDE , így hosszú" 
és a CSVDE meg , így széles". 

Az elsőben minden AD-objektum adata egymás után szerepel 
egy végtelenül hosszú listában egymás alatt. Mindenkinek 
minden adata és adatmezője szépen sorban. A CSVDE viszont 
jobban alkalmas emberi fogyasztásra mert ott.az adatokat meg- 
határozó mezők csak egyszer, egymás mellett szerepelnek az 
első vízszintes sorban. Így attól függően, hogy egy adott mező 
értelmezhető egy-egy objektumra: vagy tartalmaz adatot, vagy 
nem. Az információk objektumonként, egy-egy sorban helyez- 
kednek el. Ez a forma egy Excel táblába beolvasva jól átlátha- 
tó, kis ügyességgel szerkeszthető, kezelhető. Azt mindkét esz- 
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közről tudni kell, hogy ha az ember készít egy expor- 
tot, és megpróbálja akár azonnal, mindenféle változ- 
tatás nélkül visszatenni, nem fog sikerülni! 

Az export ugyanis tartalmaz olyan mezőket is, amik 
nem szerepelhetnek az import során. Tehát ha min- 
dent kiexportálunk, a szöveges szerkesztés elkerülhetetlen. (A 
kézi szerkesztéssel a 0276382 számú MS KB cikk foglalkozik 
részletesen. Emellett az eszközök kapcsolóival meg lehet ad- 
ni, hogy milyen objektumokat, melyik tárolóból, és melyik att- 
ribútumokkal exportálja ki. Ömleszteni egyszerűbb és gyor- 
sabb, igaz, akkor felesleges adataink is lesznek.) 

Ritkán kell, de ha kell, rettentő hasznos, hogy ezek az eszkö- 
zök a rendelkezésünkre állnak. Nekem például nem kellett 
kézzel újra létrehoznom a 48 usert meg a legalább 
ugyanennyi csoportot, meg egyéb - a userekre jellemző — 
beállításokat. Nem is emlékeztem úgysem a pontos nevekre, 
lévén, hogy nagyrészt külföldiekről van szó. De ha mindenki 
magyar nevű lett volna, akkor sem emlékeztem volna, hogy 
hány és milyen csoportot hoztam létre az elmúlt egy év során. 
Eldöntöttem tehát, hogy az exportok birtokában nekikezdek a 
teljes reinstallnak. 

Így is tettem és az Isbsrecovery] címen elérhető SBS Server 
Recovery cikk szerint elkezdtem az ott ismertetett eljárást, bíz- 
va abban, hogy a mentés, ami a rendelkezésemre áll, tartal- 
maz minden olyan adatot, ami kell. A System State-et persze 
elfelejthettem ebben a speciális esetben. De miután vége lett 
ennek az egésznek, és ez a szerver visszakerült a rackszek- 
rénybe, fogtam egy friss mentést és tesztképpen végigcsinál- 
tam lépésről-lépésre a dokumentumban ismertetett folyamatot 
egy másik gépen és a végén - szkeptikus hozzáállásom elle- 
nére is — minden a legnagyobb rendben működött! SBS 
Restore igenis létezik! Csak jó mentés kell hozzá! 

Visszatérve az eredeti szerverhez: tehát miután elkészült egy 
új -— de nevében és jellemzőiben a régivel teljesen azonos — 
SBS 2000 install, felkerültek a frissítések és programok, elővet- 
tem a CSVDE eredményét, és egy kis szerkesztés után — ami- 
nek elkészültében nagy-nagy segítségemre volt főnököm tudá- 
sa, türelme és kitartása — elvégeztem az importot, és lám, 
megjelentek az AD-ban az objektumok. Minden ott volt, ami 
kellett: Containerek, Userek, Csoportok. 
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Még egy nagy falat, az Exchange! 


Nos, ebben az esetben, mivel az eredeti System State nem jött 
vissza, az Exchange szempontjából a pillanatnyi felállás telje- 
sen új szerverként jelentkezett. Még akkor is, ha a neve, 
domainje ugyanaz volt, mint annakelőtte. Ez persze csak ak- 
kor gond, ha adatbázisszintű restore-t próbálunk. Azt ugyanis 
igencsak nehéz elfogadtatni az ,új" szerverrel, hogy megsze- 
resse egy ,másik" szerver adatbázisát, logjait. Itt majdnem 
feladtuk, mert sehol nem találtunk olyan megoldást, ami hibás 
System State mellett lehetővé teszi az Exchange disasterre- 
covery telepítését. 

Ekkor jött — sokadik álmatlan éjszaka után — a mentő ötlet: 
sHiszen a Veritas Backup Exec-nek van Exchange Agent-je, 
azaz ő ért Exchange-ül." Nosza, szedjük elő azt, és mivel a 
userek, alias-ok, csoportok a neveket tekintve pontosan 
megegyeznek a régi állapottal (a CSVDE import miatt), az in- 
dividuális mailboxonkénti mentés szépen visszatehető min- 
denkinek. Ez ugyanis nem adatbázisszintű visszaállítás. Ő 
csak az adatokat, leveleket, és egyéb mailbox-beli dolgokat 
adja oda, amit az ESE szépen betesz a helyére az ő belső lel- 
kivilága szerint. Még a beállításokat és a rule-okat is! 





Persze azért ez sem volt ilyen egyszerű. A mailboxoknak 
ugyanis fizikailag is meg kell lenniük az adatbázisban, mielőtt 
így írhatnánk beléjük, illetve kell egy mentést készíteni az 
egészről, mielőtt használhatnánk az ilyen stílusú visszaállítást. 
Fizikai meglét alatt azt értem, amit: nem elég a szerveren 
megadni, hogy X.Y.-nak legyen levelesládája, mert az 
Exchange lusta, és addig nem csinálja meg, amíg erre tényle- 
gesen nincs szükség. 

A fizikai létrehozás egyszerű: be kell lépni klienssel. Ezután a 
levelesláda már célpontja lehet egy visszaállításnak, aminek 
végeztével azért adódott még egy probléma. 

A domain régi tagjai — a felhasználói gépek — ennek az ,új 
domain-nak nem voltak tagjai. Így ki kellett venni kézzel min- 
den egyes gépet, majd visszatenni, és az újonnan létrejött lo- 
kális user-profile-okba visszamásolni az adatokat a régiekből. 
My Documents, Desktop, Favorites, stb. De ezek után tényleg 
minden működött és egy félig használhatatlan mentés birtoká- 
ban is kijelenthettük, hogy semmi nem veszett el azon az egy 
héten kívül, amíg minden állt ;-) ! 
Minden régi adat megvan és minden 
használható!!! Ötven ember egyévnyi 
munkája, pénzügyi adatai, levelezé- 
se, dokumentumai. Szinte minden, 
amin eddig dolgoztak. Valóban nagy 
szó, hogy semmiről nem kellett le- 
mondaniuk. Sőt, a régen tervezett ví- 
ruskereső-motor Írissítés helyett is 
mostmár a legújabbat tettem fel. 
Időközben kiderült a probléma tény- 


Ha van is mentésünk, 
vajon jó-e? Hihetjük 
azt is, hogy minden 


rendben. De egy 


próbát mindenképp leges oka is. Valóban hardverhibáról 
volt szó, és természetesen a memó- 
megér, hogy biztosak  riák körül volt a gond(!). Egy hibás 
modulban sorra módosultak az ott 
is legyünk benne! előforduló adatbitek, ezek ugyanígy 


kerültek kiírásra is a diszkekre. Szé- 

pen lassan — hibát hibára halmozva — 

[El összejött egy jó kis Systemcrash! De 
mint láthatjuk, semmi sem menthetetlen, csak kis kitartás és 
elszántság kell hozzá. Végső konklúzióként megemlíteném a 
teljes mentés fontosságát és a Veritas Backup Exec software 
hasznos kiegészítését, az Exchange Agentet. Enélkül ugyanis 
nem lehetséges a mailboxok egyenkénti mentése és visszaál- 
lítása. A beépített NT-Backup sem tud ilyesmit. 
Van mégvalami, ami sokat segít egy-egy ilyen helyzetben, ez 
pedig a kezdők szerencséje. Ugyanis élesben még egyikünk 
sem használta a CSVDE tool-t, így nem is kötötte a kezünket 
semmiféle előítélet, tapasztalat. Abban bíztunk csak, hogy az 
adott szituációban már semmit sem veszíthetünk. Rengeteg 
utánaolvasás és persze a kényszerhelyzet szülte feszült légkör 
eredményeként a jövőben biztos kézzel nyúlok majd ezekhez 
a ritkán használt eszközökhöz. Jótanácsként javaslom, ha le- 
hetőségünk van rá, tegyünk el egy-egy mentést az utókornak 
legalább háromhavonta, mert ha nekem ilyenem lett volna, ez 
a cikk nem lett volna ilyen hosszú... 


Füzesi Szabolcs 
fuzesiszosi.hu 
MCSA 


A cikkben szereplő URL-ek a 


http:// 


technet.netacademia.net/go?kulcsszó c 
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Windows 2000 Server Resource Kit 


A Network Management Tools II., azaz a sorozat előző részében taglalt, felhaszná- 
lókkal, csoportokkal és megosztásokkal kapcsolatos eszközök átvilágítása után, most 


tekintsünk bele egy másik világba. 


A TCP/IP udvartartásába tartozó szolgáltatások (DNS, DHCP, 
WINS) mindennaposan használt technológiák, amelyek ala- 
pos, mélyreható ismerete nélkül elképzelhetetlen egy-egy 
rendszer tervezése és üzemeltetése. A kiszolgáló- és kliensal- 
kalmazások egyaránt erőteljesen támaszkodnak ezekre a 
megoldásokra, így emiatt egy hálózat stabilitása, megfelelő 
hatásfokú működése is múlhat rajtuk (különösen igaz ez egy 
Windows 200x tartományban, ahol mint tudjuk nincs is élet 
pl. DNS nélkül). Ezen ismeretek hiányában szembesülhetünk 
még egy gonddal: elakad(hat) a törvényszerűen legrosszabb 
pillanatban megtörténő problémák gyors felismerése illetve 
megoldása. Persze, van egy Murphy törvény, vagy inkább egy 
törvényi folyomány, amely szerint ,A problémamegoldás titka 
az, hogy meg kell találnunk azt az embert, aki megoldja a 
problémainkat", de én inkább szeretem azt hinni, hogy a tu- 
dás és a megfelelő segédeszközök fontosabbak. Az utóbbiak- 
ról — miután túlestünk az érdemtelenül hosszú bevezetésen — 
lesz most szó. 


Dhcploc.exe 


Szinte minden MCP tesztben visszaköszön az a Windows 
2000 DHCP szerverekkel kapcsolatos kérdés, hogy ha minden 
beállítás korrekt és mégsem működik a szerver, mi a hiba. A 
hiba az újdonság, mégpedig az, hogy a DHCP szervert a Win- 
dows 2000 Server-től kezdve hitelesítettni kell a címtárral. 
Amennyiben az Enterprise Administrator csoport tagjaként te- 
lepítettük, a DHCP MMC-ben ezt egy egyszerű kattintással a 
szerver helyi menüjében megtehetjük (Authorize). Kis idő el- 
teltével nagyszerű vizuális élményben is részesülhetünk, hi- 
szen az eddig piros színben tündöklő kis nyíl zöldre vált a 
szerver ikonján, ha rendben lement a folyamat. De miért van 
erre szükség? A kalóz (rogue) DHCP szerverek kiszűrése miatt, 
amelyek jelentősen bomlaszthatják jól működő hálózatunk 
szerkezetét, abban az esetben ha valamelyik ,kollégánknak" 
direkt avagy véletlenül sikerült egy saját, mondjuk nem túl 
korrekt beállításokkal rendelkező DHCP szervert üzembehe- 
lyezni és aztán magához csalogatni a klienseket. Ilyen illegá- 
lis DHCP szerverek felfedezésére használható (NT4 Serveren 
is, ahol nincs hitelesíttetés) a DHCP Server Locator Utility 
azaz Dhcploc.exe. 


Az eszköz csak a saját alhálózatán tud DHCP üzeneteket el- 
fogni és működéséből adódóan nem futatthatjuk magán a le- 
gális DHCP szerveren sem [0186462]. Ha megfelelően para- 
méterezve elindítjuk, szépen elkezdi a hálózat lehallgatását, 
figyeli a speciális DHCP csomagokat és ki is írja ezeket auto- 
matikusan. Futás közben három billentyűvel adhatunk ki pa- 
rancsokat (ezt egyébként sehol nem jelzi) ,d" mint Discovery 
(azaz ajánlatkérés, ha másra nem, erre majd csak felfigyelnek 
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a DHCP szerverek), ,g" mint OXuit és ,h" mint Help. Abban az 
esetben, ha a program kalóz DHCP szervert talál, sípol és egy 
figyelmeztetést is küld. A következő példa alapján kideríthe- 
tünk egy s mást a szintaxisról is: 





Látható pl. hogy a ,-p" és a parancs végén a ,legalis.txt" 
használata az általunk megadott, korrekt DHCP szerver(ekJet 
már eleve kiszűri a vizsgálatból. Az ,-a" kapcsoló után lévő 
szövegállományban azt a címzettet kell megadni, ahová a fi- 
gyelmeztetés megy, az ,,-i" az automatikus vizsgálat interval- 
luma másodpercben, az IP cím pedig az alkalmazást futtató 
gép címe. A kimenet részlete lehet például valami hasonló: 





Az oszlopokban az időpont, a kliens IP címe illetve az aján- 
lat/jóváhagyás típusa és az ajánló szerver IP címe látszik. A 
három csillaggal jelzett szerverekkel van a baj, valószínűleg 
megértek a likvidálásra! 


Dhcpobjs.exe 


A már többször emlegetett Windows 2000 Server Support 
Toolsban létezik egy dncpadm.exe, amellyel parancssorból le- 
het irányítani a DHCP szerver általános és alapvető funkcióit. 
De nem mindent. A ,minden", ami kiegészíti a dhncpadm.exe 
lehetőségeit, az a Resource Kitben szereplő DHCP Objects 
csomag. Ennek feltelepítése után lehetővé válik alkalmazások- 
ból illetve VBScript és JavaScript szkriptekből a DHCP szerver 
teljeskörű távoli üzemeltetése és felügyelete. Ez a komponens 
alapból nem települ fel a Resource Kittel, külön kell kicsoma- 
golni az .exe-ből, majd a szükséges diI állományt is nekünk 
kell manuálisan regisztrálni a regsrv32.exe-vel. A csomagban 
érkezik még egy Dhcpobjs.chm nevű HTML formátumú súgó, 
amely nagyon részletes és tele van példákkal. 


Dhcpexim.exe 


Ha már a vizsgakérdéseknél tartunk, bizonyára sokan emlé- 
keznek arra is, hogy szintén sűrűn sor kerül a DHCP adatbá- 
zissal kapcsolatos mentési, mozgatási műveletek firtatására, 
ezért célszerű ismerni a manuális módszert. Ennek lépései 
dióhéjban: a regisztrációs adatbázis idevágó kulcsának ex- 
portja, majd a System.mdb állomány átnevezgetése és végül 
registry import abból a célból, hogy egy másik (vagy akár 
ugyanazon) gépen a sikeres visszatöltés után változatlan álla- 
potot tudjunk prezentálni. 
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Ez a módszer jól jön abban az ismert szituációban 
is, ha szervert váltunk és előtte már kismillió tételt 
bejegyeztünk (illetve automatikusan bejegyzésre ke- 
rül) ebbe az adatbázisba. A teljes művelet 
[0130642] kissé macerás dolog, de muszáj, mert a 
DHCP szerverben nincs mentési lehetőség és az 
NTBackupnak sincs ilyen opciója. 

De hogy mégse legyen annyira muszáj, ebben az esetben is 
segít rajtunk a Resource Kit, pontosabban a ,nagy" Resource 
Kit szűkített, letölthető változata, amelyben szerepel egy erre 
a célra tökéletesen használható és ezért igen szimpatikus esz- 
köz a DHCP Database Export Import Tool, amely innen 
[dhcpexim] beszerezhető. 


DhcpExim Export [2 


Select the scopes that will be exported to Ciaza 






[10.0.0.0) TJSZKINET 
[172.16.0-0] ALTGRI 


T Disable the selected scopes on local machine before export. 


Cancet 


B Választhatunk a hatókörökből az export során 


Az eszközt nagyon egyszerűen csatasorba tudjuk állítani, gya- 
korlatilag egy varázsló végigvezet az export ill. az import lé- 
pésein. A telepítés után a Resource Kit mappában találjuk meg 
(akkor is, ha nincs meg a teljes Resource Kitünk). A ,varázs- 
lás" során kiválaszthatjuk a menteni kívánt hatókört, és termé- 
szetesen nemcsak a bejegyzett címeket, hanem az egyéb beál- 
lításokat (DNS szerver(ek), WINS szervert[ek), átjárók, stb. cí- 
mei) és a rezervációkat is elmenti. Vegyük figyelembe, hogy a 
varázsló leállítja a DHCP szolgáltatást, amíg az export/import 


megy! 
Enabledhcp.vbs 


Újabb okosság: ennek az apró kis szkriptnek a segítségével 
parancssorból, távolból lehet reszetelni egy-egy gép manuális 
TCP/IP beállításait és aztán a DHCP szerverre , kötni". Kényel- 
mes dolog a szerverről futtatva átállítani így a kliensgépek tu- 
catjait, de akár a laptopos ügyfelek számára is készíthetünk 
egy parancsikont, amire a felhasználó csak rábök és máris 
bent van a hálóban, látja az összes - a DHCP szerverben beál- 
lított - fontos hálózati szolgáltatást nyújtó kiszolgálót. A szin- 
taxis két része oszlik, ám mindkettőnél a cscript.exe-vel kell 
futtatni a szkriptet (az xpsp1 a távoli gép neve): 


csceript EnableDhcp.vbs /L /S xpspl 


Az első példában az /L kapcsolóval tudjuk lekérdezni a távo- 
li gép (összes) hálózati kártyáján futó szolgáltatásainak nevét. 
A /§ kapcsoló mindig a kliens gép nevét feltételezi, azaz an- 
nak a , Server" szervizét. Az így kiadott parancsra egy hason- 
ló listát kaphatunk, mint az alábbi képen. 








mescript enabledhcp.ubs /L /s xpspi 
icrosoft (RD) Windows Script Host Version 
opyright (C) Microsoft Corporation 1996-2801 . AL1L1 rights reserved. 


Ba 


B A kliens hálózati kártyáján futó szolgáltatások 


Ezek közül ki kell választanunk azt, amelyikkel a helyi háló- 
zathoz csatlakozunk (jelen esetben a PCNet5 5 vmware), Ezt 
az /A kapcsoló után kell megadnunk. Az /U és az /W kapcso- 
ló magáért beszél. Az eredmény pedig lementhetjük az /O 
kapcsoló után megadott állományba. 


EnableDhcp.vbs /A PCNet5 /S xpspl /U Administrator 
/W password /O c:Venabledhcp log.txt 


Winscl.exe 

A kérdésre, hogy kell-e nekünk a WINS (Windows Internet 
Name Service) — azaz DNS helyettese illetve a Windows 
9x/NT operáció rendszerek illetve az ezekre a platformokra írt 
alkalmazások esetén az elsőszámú névfeloldást segítő szolgál- 
tatás egy TCP/IP-vel működő helyi hálózatban — nem könnyű 
válaszolni. Ha teljesen Windows 2000 Server kompatibilis 
klienseink vannak, és egyáltalán nincs szükségünk a problé- 
más NetBIOS névfeloldásra, a redundancia miatt még mindig 
jó lehet a DNS helyett. De ha vannak még pl. Win9x/NT 
klienseink is (és még mindig rengeteg helyen így van), nem 
sok választási lehetőségünk van, szinte muszáj használni. 

Ha pedig kell a WINS, akkor szükség lehet a parancssori 
WINS Administration Toolra is, amellyel ellenőrizni tudjuk a 
WINS forgalmat, valamint megvizsgálhatjuk a szépen hízó 
adatbázist is. Az eszköz interaktív üzemmódban működik 
mint pl. az nslookup, de mégsem teljesen úgy: az elindítás 
után mindig látható a teljes parancskészlet illetve ezek 2-4 be- 
tűs rövidítése. Képes rábírni a WINS szervert olyan műveletek 
elvégzésére mint pl. a replikáció, a takarítás (scavening), re- 
kordok regisztrálása, törlése és lekérdezése az adatbázisból, a 
mentés és/vagy visszaállítás vagy éppen az inkonzisztencia 
vizsgálat. 


A WINS és a DNS témakörével kapcsolatos további Resource 
Kit segédeszközök tallózása következő számban folytatódik. 


Gál Tamás 
MCSE 2000 
gtamasátjszki.hu 


[Megállás nélkül 


99, 99995-os rendelkezésreállás Windows 


operációs rendszerrel? 


A cél az ,ötkilences" rendelkezésreállás. Évente 5 perc leállás. Ilyenkor aztán beindul az agyalás: 
Hogyan? Farkasokkal táncolunk, clustert építünk és fürtözünk? Ide ez már nem elég. Ez már egy más 


kategória, itt a fürt hamar elvérzik. Ide Stratus kell! 


Mi a baj a fürtökkel? 





Amíg szőlőről van szó, semmi. Finom bor készül belőle. Az 
informatikában azonban más a helyzet. Mi a fürt? 
Összekapcsolt gépek halmaza, melyen erőforrásokból álló 
csoportokat definiálunk. Az erőforrások függőségi viszonyban 
állhatnak egymással. Ha bármiféle probléma van, egy erőfor- 
rás elhasal, majd a kapcsolatok függvényében a többi is, ez ki- 
váltja az adott csoport vándorlását. A futtatott alkalmazás át- 
költözik egy másik gazdagépre. A beállított szabályoknak 
megfelelően persze vissza is tud sétálni. Egyszerű. Valóban? 
Itt szeretnék eloszlatni egy félreértést: fürtöt nem lehet venni. 
Fürtöt csak építeni lehet! (Aki rakott már össze fürtöt, az tud- 
ja, hogy miről beszélek.) Elő kell kapni a fürttéglákat (2-3-4 
szervergép, megfelelő eszközökkel) és a fürtmaltert (2-3-4 
szerver licensz - 2-3-4 alkalmazás licensz, tipikusan az ,űr- 
hajó" változat), és lehet kezdeni az építkezést. Egy kritikus 
feladat kiszolgálására hivatott fürt építése gondos (és időigé- 
nyes) tervezést, tesztelést igényel, és az implementáció is 
meglehetősen összetett feladat. A kialakított fürt üzemeltetésé- 
ről nem is beszélve. Mi szükséges ehhez? Rengeteg erőforrás 
(szakember, idő, pénz). Az első nagy koppanás — szerencsés 
esetben a felmérés, tervezés során - akkor következik be, ha a 
kritikus alkalmazás nem fürtözhető (nem cluster-aware). 
Ilyenkor jöhet az erőlködés, hogy ,de mégis". Nem javaslom. 
A valódi probléma azonban magában az elképzelésben van. 
Mi a fürt célja? A helyrehozás (recovering)! Na itt bukik meg 
az ,ötkilences"... Figyeljünk csak: A hiba bekövetkezése után, 
a fürt gondoskodik a kritikus szolgáltatás (alkalmazás) hely- 
reállításáról. A helyreállítás időt igényel, és a kritikus szolgál- 
tatás ez alatt szünetel. 


Az ötlet 


Az ötlet egyszerű. Készítsünk olyat, ami ,nem romlik el". Itt is 
igaz — az orvosok által gyakran ismételgetett - bölcsesség: a 
,megelőzés sokkal hatékonyabb, mint az utólagos kezelés". 


Meg is érkeztünk a Stratus filozófiájához: a leállást elkerülni 
kell, és nem minimalizálni! 


Stratus 


Az elképzelés működik. A Stratus ftServer hibatűrő szerverek 
99.99996 rendelkezésre állást biztosítanak a Microsoft Win- 
dows 2000 alapú rendszerek számára. Mit jelent ez a gyakor- 
latban? Egy ftServer két nagyságrenddel jobb rendelkezésre ál- 
lást nyújt, mint egy WINTEL alapú kiszolgáló fürt! Szépen 
hangzik, de hogyan lehetséges? 

Nem is olyan régen Bill Gates meghirdette a Trustworthy 
Computingot. Felismerte, hogy egy rendszert nem lehet utólag 
biztonságossá tenni. Valódi eredményt csak úgy lehet elérni, 
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ha a biztonság a legelső gondolattól kezdve szerves része a 
fejlesztésnek. Secure by design. 

Hasonló a helyzet a megbízhatósággal és rendelkezésre- 
állással is. Amikor hagyományos gépekből építünk fürtöket, 
az egyébként , megbízhatatlan" gépekből próbálunk megbíz- 
ható rendszert építeni. Több-kevesebb sikerrel. 

Ha valóban megbízható rendszert szeretnénk építeni, az ala- 
poknál kell kezdeni, és már a tervezés első lépésétől kezdve a 
megbízhatóságnak kell lennie a fő célnak. Ezt a módszert kö- 
vette a Stratus is. Reliability by desing. 

Az eredmény egy egészen speciális hardverarchitektúra lett. 


Hibatűrő hardver 


Egy Stratus belül alig hasonlít a hagyományos szerverekre. 
Minden komponens duplán, vagy triplán található meg ben- 
ne. Dupla, tripla CPU, memória, merevlemezek, PCI kártyák, 
ventillátorok, tápegységek speciális hibaérzékelő és elszigete- 
lő rendszerrel ellátva. Nincs , single point of failure". 
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a Hibatűrő architektúra 


Speciális HAL 

A komponensek többszörözése önmagában még nem lenne 
elegendő a sikerhez, az operációs rendszert is fel kell készíte- 
ni a hibatűrő architektúra kezelésére. Ezért a Stratus - a Mic- 
rosofttal együttműködve —- speciális HAL-t (Hardware 
Abstraction Layer) készített szervereihez. Így a szerveren futó 
operációs rendszer, és főleg a futtatott kritikus alkalmazás nem 
érzékeli az egyes komponensek meghibásodását. Mit jelent 
ez? Nincs leállás. Gyakorlatilag alkatrészenként a komplett 
gépet ki lehet cserélni menet közben, miközben az alkalma- 
zás folyamatosan működik. A fürtökre jellemző átállási időt is 
el lehet felejteni, mert nincs. 


Driverhibák nélkül 


A hibás driverek előkelő helyen állnak minden üzemeltető fe- 
ketelistáján. Számos probléma és összeomlás valódi oka egy 
hibás eszközmeghajtó. A becslések szerint az NT-nél az új- 
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Megállás nélkül 


lé 


raindulások, és rendszerhibák több mint 3095-át hi- 
bás eszközmeghajtó okozta. A Windows 2000 eseté- 
ben a Microsoft sokat szigorított az eszközmeghaj- 
tók tesztelési és minősítési eljárásain, de a hibás esz- 
közmeghajtók ennek ellenére még mindig nagyon 
sok problémát okoznak. 

A Stratus ennek ismeretében a legnagyobb körültekintéssel fej- 
leszti ki és teszteli a szervereiben használt eszközök meghaj- 
tó programjait, így minimalizálva ezt a jelentős kockázati té- 
nyezőt. 


Beépített szerviztechnológia 


A beépített szerviztechnológia a folyamatos működés egyik 
kulcsa. Ezek a szoftver- és hardverelemek folyamatosan el- 
lenőrzik a kiszolgáló működését. Ha egy komponens meghi- 
básodik, azt azonnal elszigetelik, és rendszer automatikusan 
bejelenti a hibát a szervizközpontba. Amennyiben a hiba 
megoldható a kiszolgáló management kártyáján keresztül, a 
szervizközpont . on-line beavatkozik, amennyiben nem, a 
helyszínen kicserélik a hibás komponenst. Természetesen ez a 
felhasználók számára teljesen láthatatlan, mert a szolgáltatá- 
sok ez idő alatt is folyamatosan működnek. Miért fontos ez a 
szerviztechnológia? Mondok egy példát: gondoljuk csak a 
mindenki által ismert RAID technológiára. Ennek a — manap- 
ság szerencsére már mindenki számára elérhető — technoló- 
giának az a lényege, hogy a diszk alrendszer valahány (tipiku- 
san 1) diszk meghibásodását adatvesztés nélkül elviseli. Ezt a 
rendszer valóban el is viseli. Meghibásodik egy diszk, a rend- 
szer ugyan lassul, de az üzemeltetés esetleg nem vesz észre 
semmit, hiszen minden működik. Akkor lesz igazán baj, ha a 
következő diszk is felmondja a szolgálatot. Két lemez meghi- 
básodását (konfigurációtól függően) a rendszer nem képes el- 
viselni, itt a hiba, a leállás. Ha az első hibás lemezt azonnal 
kicserélték volna, a rendszer visszanyerte volna hibatűrő ké- 
pességét és működhetne tovább. Tehát az egyébként kifogás- 
talanul működő technológia is hatástalan megfelelő jelzés, 
üzemeltetés és felügyelet nélkül. 


Üzemeltetés 


Szép feladat rendszereket építeni, de az igazán kemény 
feladat a rendszermérnökök által összerakott és dokumentált 
rendszer életben tartása. A Stratus esetében ez meglehetősen 
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egyszerű, hiszen — a fürtökkel ellentétben — egy operációs 
rendszer fut rajta, és az alkalmazás is csak egy példányban 
működik. Nem kell fail-over scripteket írni, tesztelni, és ag- 
gódni a fürt aktuális gyermekbetegségei miatt. A kifinomult hi- 
baérzékelő és izoláló rendszer gyakran a tényleges meghibá- 
sodás előtt képes a mért paraméterek segítségével előre jelez- 
ni a problémát, értesíteni az üzemeltetést és a szervizt. 


Uptime meter 


Szép gondolatok, de ismét felmerül a kérdés: mit jelent ez a 
gyakorlatban? Az eredményt bárki megtekintheti, a Stratus 
weboldalán (www.stratus.com) lévő uptime meter a jelenleg 
menedzselt ítServer-ek rendelkezésreállását jelzi (a telepített 
szerverek 8096-a). A cikk írásának időpontjában a számláló a 
következő értéket mutatta: 


tratus Uptime Meter" 
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Hová? 


Szükséges ekkora rendelkezésre-állás? Ez nem technológiai 
döntés. A választ a védeni kívánt alkalmazás/ok ismeretében 
az üzleti döntéshozóknak kell meghoznia. Napjainkban az 
üzleti szempontból kritikus alkalmazások elérhetőségével 
kapcsolatos elvárások egyre magasabbak. Egyre kevesebb 
szervezetnél fogadható el az ügyviteli rendszer, az elektroni- 
kus levelezés, vagy az adatbáziskezelő 8 órányi leállása. 

A múltban ötkilences rendelkezésreálláshoz sok millió dollá- 
ros űrhajók beszerzésére volt szükség, többnyire teljesen spe- 
ciális operációs rendszerrel és alkalmazásokkal. 

A jó hír a következő: ez a megbízhatósági szint elérhető szab- 
ványos Windows platform használata mellett, a megszokott 
WINTEL árszinten is. 
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A DHLP rejtett szépségei 7 ID. 


Egy végső lendülettel megbirkózunk a DHCP utolsó nagy fogalomkörével, vagyis az 


osztályokkal és opciókkal. A cikksorozat második részében már megemlítettük a leg- 
fontosabbakat, de túlságosan nem merültünk el a részletekben. Most viszont épp ezt 
fogjuk tenni, hogy megértsük, milyen eszközeink vannak az ügyfelek finomhangolására, s egyáltalán: 


mi mindenre képes a DHCP... 


Az opciókról általában 


Az opciók lényegüket tekintve paraméterek, amelyeket az 
ügyfél megkap, feldolgoz vagy éppenséggel elvet. A szabványt 
úgy alkották meg, hogy a DHCP-csomagokban opciók tömke- 
lege, egészen pontosan legfeljebb 312 byte (oktet) vándorol- 
hat a kiszolgálóról a klienshez. Csoportosításukkal világos ké- 
pet alkothatunk, hogy mikor kell beállítani egyet-egyet, s mi- 
kor nem. 

Többféle rendezés is elképzelhető. Technikai értelemben lé- 
teznek információopciók (information options) és protokoll- 
opciók (protocol options). Az információopciókat explicit mó- 
don be kell állítani, hogy érvényre jussanak. Az alábbiak mind 
ennek a csoportnak tagjai: 


8 Router 

6 DNS kiszolgáló 

15 DNS domain név. 

44 WINS kiszolgálók 

46 WINS/NetBIOS node típus 
47 NetBIOS Scope ID stb. 


A protokollopciókat ezzel szemben csak implicit módon lehet 
megadni a bérlettartomány létrehozásával és konfigurálásával, 
vagyis egy scope létrehozása részben DHCP-opciók megadá- 
sa, még ha ezt el is rejti a felhasználói felület. 


0.0] MAL-W2000 Properties [edd 
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General JDNS. ] Advanced] 


17 Scope 








Scope name: 
StartIP address: [ 10. 0. 1.1 


EndiIP address: 10. 0. 5.254 








Subnet mask 255.255. 0 0 Length: 16 
- Lease duration for DHCP clients 
G Limited to: 
Days: Hours: Minutes: 
o zi o d 0 a 
C Unlimited 
Description: B MÁL Székesfehérvári telephelyének DHCP be 





A bérletidő megadásával az 51-es, 58-as és 59-es op- 
ciót is beállítjuk. A subnet mask opciószáma T. 





Az alább felsoroltak mind a protokollopciók közé tartoznak: 





51 ml 

53 

55 ———— Igényelt paraméterlist 

58 Megújítási idő (Renewal time) 
59 Címkérési idő (Rebind time) 


Létezik másfajta csoportosítás is, ekkor az alapvető jellemző 
az a hatókör, amelyben a paraméter felhasználható. Ez alap- 
ján megkülönböztethetünk: 
1. Szerver avagy default global opciókat 
2. Scope opciókat 
3. Class opciókat, amelyek lehetnek User class és Vendor 
class opciók 
4. Kliens opciókat, amiket lefoglalt (reserved client) op- 
cióknak is hívnak. 


Mindez persze nem jelent pontos egymásba ágyazódást. A 
szerver-scope-client opciók még jól követhetők a konzolon is, 
ám a user class és a vendor class opciók a szép egymásba ágya- 
zódást keresztülszelik, mert elvileg bárhol előfordulhatnak. 








B E mal-corpserv .mal.priv [10.0.0.24] 
Z CI Scope [10.0.0.0] MAL-W2000 004 ——— 002 Microsoft 003 
T Address Pool Időkászolgáló Release DH,., Útválasztó 


(ÖÖ Address Leases új ő ag 
4 oP X 


A CA Reservations 
ZA [10.0.0.71] NPI67DEBB. mal 
ke a Ke 006 015 044 
DNS-kiszolg. .. DNS-tartom, .. . WINSZNBN, ., 


(4 Scope Options 
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C3 Server Options 
046 051 Bérlet 


WINSJNBT-. .. 
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B A szerver, a scope és a client opciók egymásba ágya- 
zódnak 


Az erősorrendet ezzel együtt nem nehéz felállítani. A leggyen- 
gébb opció-csoport a szerverhez kötődik. Ezek minden bérlet- 
tartományban érvényre jutnak, hacsak a scope-ban definiáltak 
felül nem írják őket. k 

A bérlettartományhoz rendelt opciók a leggyakoribbak. Min- 
den ügyfél megkapja őket, és amennyiben érti, fel is dolgozza 
azokat. Mit is jelent ez pontosan? Nos, előfordul, hogy egy 
ügyfél olyan paramétert is kap, amely őt nem érdekli. Például 
egy Windows for Workgroups 3.11-es ügyfelet egyáltalán nem 
foglalkoztatja a hálózatban fellelhető NIS szerverek IP-címe 
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J8) — ] (Option 41), ugyanakkor egy Linux rendszer számá- 


] ra meghatározó információról lehet szó. A WfWw 

ül, ] 3.11.-be egyszerűen nem programozták bele vala- 

mennyi opció feldolgozását, így az csak a számára 

relevánsakat fogja megérteni. S melyek ezek? Ezt 

már szintén érintettük korábban, de nem árt ismételni. A Mic- 
rosoft ügyfelek által használt paraméterek a következők: 












Router 

DNS Servers 

Domain Name jéta 

WINS/NBNS Servers 

WINS/NBT Node Type 

NetBIOS Scope ID 
se e 






Inverz szedéssel jelöltem a protokollopciókat — ezeket a rend- 
szer mindenképp kiadja, ahogy azt már kicsit korábban láttuk. 
Visszatérve az erősorrendhez: a szerveropciókat felülírhatják 
a scope-opciók, azokat pedig a kliensopciók. Ezt a sort színe- 
sítik némiképp az opcióosztályok. 


Opcióosztályok (option classes) 


Az osztályokat azért hozták létre, hogy további finomításokat 
végezhessünk a címkiosztási rendszerünkön. Nem kötele- 
zően, de általában a scope-on belül definiáljuk azokat a beál- 
lításokat, amelyeket egy meghatározott osztályhoz szeretnénk 
rendelni. 

Aki figyelmesen megnézi a bérlettartományhoz tartozó para- 
méterek részletes listáját, láthatja, hogy az oszlopok között 
szerepel egy ,vendor" (szállító) és egy ,class" (osztály) elne- 
vezésű is. Egy hétköznapi opció, például a 15-ös szállítója 
sStandard", osztálya pedig , none". 

Ebből az következik, hogy egy opcióhoz rendelhetünk szállí- 
tót és osztályt is, sőt akár mindkettőt egyszerre. Az alábbi áb- 
rán látható, hogy a 002-es a , Microsoft Options" kategóriába 
tartozik, a 051-es pedig a ,Default Routing and Remote 
Access" osztályba. 
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E Szállítók és osztályok alkalmazás az opciók között 


Mi is a fenti konfiguráció értelme? A 002-es opció érvényre jut 
minden , Microsoft Options" szállítói kategóriába eső ügyfél- 
nél. Melyek ezek? A Windows 98 és annál frissebb, valamint 
a Windows 2000 és annál frissebb MS rendszerek. Az NT4 
miért nem? Mert a szabvány, amely az osztályokat és a szállí- 
tói opciókat definiálta 1997-es keltezésű, tehát az NT4 meg- 
jelenése után alkották. És honnan tudja egy Windows 2000-es 
ügyfél, hogy ő ebbe a szállítói kategóriába tartozik? Ezt egy- 
szerűen tudja, mert a szállítója beleprogramozta. Bármely 
szállító (Pl. Xerox, Cisco, Motorola, Ericsson stb., stb.) defi- 
niálhat saját opciókat és saját szállítói osztályokat, amelyeket 
azután a DHCP szolgáltatás ki tud osztani a megfelelő szállí- 
tóazonosítóval rendelkező ügyfelek számára. 


Nézzük meg mindezt egy fiktív — ám mégis lehetséges példán. 
Tegyük fel, hogy hálózati nyomtatók gyártására szántuk el ma- 
gukat, a cég márkanevéül pedig a nem túl fantáziadús, ám jól 
csengő HunPrint nevet adtuk. A nyomtatónkat felkészítettük 
arra, hogy egy DHCP kiszolgáló segítségével távolról konfigu- 
rálni lehessen azt az időt, ami után, ha használaton kívül van 
a gépünk, automatikusan energiatakarékos üzemmódba 
(standby) vált. A nyomtató operációs rendszerébe beágyaztuk 
a megfelelő kódot, és tudattuk vele, hogy a HUNPRNT szállí- 
tói osztály tagja. Ezek után ezt az osztály létre kell hoznunk a 
DHCP kiszolgálón is. A konzolon kattintsunk a jobb egér- 
gombbal a szerveren, majd válasszuk a ,Define Vendor 
classes..." pontot. A három, előre definiált osztályt láthatjuk, 
ezt a listát kell kiegészíteni a sajátunkkal. 


DHCP Vendor Classes KIE 


Avallable classes: 
Name 
Microsolt Options 

Microsoft Windows: 2000 Options 
Microsoft Windows 98 Options 
Hunprint Options 










Description 
Mictosoít vendor-specific options appli 
Microzoft vendor-specific option: for Edit 
Microsoft vendor-specific options form 

Hunprint Opciók BHemove 





Display name: 
Desciiptiorr 


Hunpint Opciók 


1D: Binary: ASOL 
10000 48 55 4E 50 52 4E 54 HUNPRNT 


mm 


Szállítóosztály készítése 


Ezután a fenti context-menüt újra előcsalogatva definiálha- 
tunk egy új beállítást a ,Set Predefinied Options..." funkció 
segítségével, sőt, még alapértelmezett értéket is adhatunk neki. 


Predefined Options and values KEI 
Hunprint Options ké 








Option class: 
Option name: 099 Standby time m 
Edit.. I Delete 
Description: [Pefine time in second after Hunprint devices goe 
Value 
he 
! [60 


E Definiáltunk egy saját opciót a nyomtatóinkhoz 


Ha a fenti opciót kiajánljuk egy bérlettartományban, minden 
eszköz, amely a szállítói osztálynak tagja (vagyis a nyomta- 
tóink), gond nélkül alkalmazni fogja. 

Persze mi nem fogunk nyomtatógyártásba kezdeni, de lehet- 
séges, hogy a fenti neves gyártók egyike-másika élni fog a le- 
hetőséggel, hogy precízebb beállításokkal lássa el a gyártmá- 
nyait a DHCP szolgáltatás segítségével. 

A fenti példával analóg módon lehetséges user class és user 
class option létrehozása is, ám ekkor alkalmazhatunk egy to- 
vábbi trükköt is. 

A beállításánál az , Advanced" fülre kattintva kiválaszthatjuk, 
hogy melyik szállítói osztályból szeretnénk opciót beállítani. 





Scope Options KiEi 


General. Advanced ] 


Vendor class: DHCP Standard Options 3 ] 
User class: Default Routing and Remote Access Class -] 











Available Options.) Description 
051 Bérlet Sz ügyfél IP-címbérleti ideje másodpercekben § 
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ese entry ] 


8 Előre beállított User class opció alkalmazása 


Az opciók többsége a , DHCP standard Options" szállítói osz- 
tályba tartozik. Az azonban, hogy mely user classba soroljuk, 
rajtunk múlik. Így lehetséges, hogy egy opciót másik user 
classba sorolunk, mint az alapértelmezett. Melyikbe sorolhat- 
juk? A Windows 2000 DHCP implementációja 3 előre defi- 
niált user classt ismer: 


A Default user class 
A Default remote access class 
BA Default BOOTP class 


Az elsőbe tartozik minden ügyfél, aki nem definiált magának 
user classt. A másodikba tartoznak a Microsoft ügyfelek, ha 
betárcsáznak, a harmadikba pedig a BOOTP ügyfelek. 

Ezek kívül természetesen magunk is létrehozhatunk user 
classt. Ha például szeretnénk, hogy minden gép, amely a hu- 
mánpolitikai . osztályon — működik, — egy alternatív 
alapértelmezett átjárót használjon, akkor létre kell hoznunk 
egy HUMAN user classt, be kell állítanunk egy 03-as opciót 
hozzá, végül konfigurálnunk kell valamennyi gépet a humán- 
politikai osztályon. Ezt a régi ismerős ipconfig paranccsal vé- 
gezhetjük el 


P:Vbipconfig 
human 4 






Windows IP 


Az adapter. 
osztályazo 






Sajnos jelenleg egy adott host csak egyetlen user classnak le- 
het tagja, mivel a szabvány csak egyetlen ASCII stringet hasz- 
nál az ügyfelek azonosítására. Ezért ha van egy ,human" osz- 
tályunk és egy ,mobil" osztályunk, a mindkét osztályba tarto- 
zó gépekhez egy külön osztályt kell definiálnunk, például 
,human-mobil" néven. 


A szállítói és a user class közötti különbséget jól szemlélteti a 
fenti két példa. Bár mindkét módszer az ügyfelek szelektív 
konfigurálására szolgál, az egyik a gyártóspecifikus konfigurá- 
ciós paraméterek továbbítására tervezték, míg a másik a rend- 
szergazdák által valamilyen kritérium szerint felállított ad-hoc 
csoportok elkülönített paraméterezését segíti. 

Az ábrákon egyébként nem véletlenül szerepelt többször is a 
Default Routing and Remote Access Class. Ennek az osztály- 
nak a segítségével elérhetjük, hogy az RRAS ügyfelek csak rö- 
videbb ideig kapjanak DHCP címeket úgy, hogy a 051-es op- 
ció segítségével lerövidítjük a bérletidőt. 


al 
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Miután áttekintettük mindazt, amit az opciókról tud- 
ni érdemes, egy elméleti kérdést meg kell válaszol- 
nunk: Vajon miért nem alkalmaz szélesebb körben 
opciókat a Microsoft az operációs rendszereiben? A 
user class azonosítókkal például LPR nyomtatókat 
lehetne megadni egy-egy osztálynak, vagy be lehetne állítani 
egy idő-kiszolgálót stb. stb. Ehelyett a világelső szoftvercég is- 
mét letér az Internetes járt útról és csoportházirendeket fabri- 
kál (ahol például éppúgy meg lehet már adni az alapértelme- 
Zett átjárót, a DNS szervereket, a DNS prefixet és lehetne még 
sorolni). 

A válasz kézenfekvő: a DHCP szabvány 312 bájtnyi adatot 
(paramétert) továbbíthat. Ez bizony egy tisztességes házirend- 
hez kevés. Ráadásul bonyolult adatstruktúrák sem közvetíthe- 
tők a DHCP segítségével. A testreszabhatósága, az ügyfelek 
megkülönböztetése sem túlságosan kifinomult (pl. az Active 
Directoryhoz képest.) Summa summára: a csoportházirend- 
nek van helye a nap alatt. 

És akkor hosszútávon DHCP-re nem lesz szükség? Hát, hosszú 
távon ott van ugye az IPv6, ami sokkal inkább képes konfigu- 
rálni magát, mint az IPv4, tehát a DHCP súlya valamennyire 
csökken majd. Az IPv4 világban azonban várhatóan mindig is 
megmarad, mert az eredeti funkciójára, vagyis az IP címek 
kiosztására továbbra is ez a legalkalmasabb módszer. Ami pe- 
dig a Microsoft ügyfélrendszereket illeti, egyre több DHCP- 
opciót fogadnak el, s mire beköszönt az IPv6-korszak, talán 
mindet ismerni fogják — de addigra kihal a DHCP. 
Szerveroldalon ugyanakkor várható, hogy az újabb verziók 
követni fogják a DHCP szabványok változását, hiszen nem- 
csak Microsoft ügyfeleket kell kiszolgálniuk, s más rendszerek 
esetén — ha nincs házirend — marad a DHCP. 


Lepenye Tamás, MCSE 2000 
lepenyetemal.hu 


Felhasznált és ajánlott irodalom 
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Internet Information 5erVÍCes 
EsZ] 6.0, IV. rész 


Levelezőszolgáltatások a Windows Server 


2003-bafr a POP3 


Régóta vártunk arra, hogy a levelek fogadásáért és kiküldéséért felelős SMTP-szolgáltatás mellett a fel- 
használók postafiókját és az ahhoz való hozzáférést biztosító POP3 is megjelenjen a palettán. A Win- 
dows Server 2003-ban végre itt van — kicsit butuska, kicsit egyszerű, de a mienk :-) 


A POP3 protokoll 


A POP3 protokoll segítségével a felhasználók letölthetik a le- 
velező-kiszolgálóra, részükre beérkezett, és ott — saját posta- 
fiókjukban - tárolt leveleket. A postafiókok karbantartása a 
POP3-kiszolgáló feladata. A felhasználó a levelek letöltése 
után törölheti, vagy akár a kiszolgálón meg is tarthatja a pos- 
tafiókban tárolt leveleket. A POP3 protokollt az ÍRFC1939] 
definiálja, magyar leírását az Olvasó megtalálhatja a tech.net 
magazin 2000. decemberi számában, illetve a [tudpop3] címen. 


A POP3 szolgáltatás 


A POP3-kiszolgáló tehát lehetővé teszi a felhasználók posta- 
fiókjába érkező levelek letöltését, de ennél többet nem tud. A 
beérkező (és főleg, kiküldött) leveleket továbbra is az IIS 
SMTP-szolgáltatása kezeli. Ha azonban figyelmesen elolvas- 
tuk az előző részben az SMTP-tartományokra vonatkozó soro- 
kat, emlékezhetünk, hogy az SMTP-kiszolgáló tudása kimerül 
abban, hogy az egy-egy adott tartományba érkező leveleket (a 
címzett ellenőrzése nélkül) egy közös mappába, a Drop 
könyvtárba helyezi el. Eddig szó nem volt felhasználókról, és 
postafiókokról. A kérdés — a hiányzó láncszem — tehát az, 
hogy az SMTP által fogadott, és tömegesen gyűjtött levél ho- 
gyan kerül be a POP3 által kezelt megfelelő felhasználói pos- 
tafiókba? 

Nos, a válasz erre is a POP3 szolgáltatásban rejlik. A POP3- 
kiszolgáló telepítése után összekapcsolódik az SMTP-vel, és 
ezután az nemcsak a beérkező leveleket szortírozza szét szé- 
pen a regisztrált felhasználói postafiókok között, de még azt is 
ellenőrzi, hogy létezik-e egy-egy beérkező levélben szereplő 
e-mail cím az általa kezelt tartományban. A POP3 tehát nem 
létezik az SMTP nélkül, az SMTP pedig nem képes a levelek 
szétválogatására a POP3 segítsége nélkül. Ennek a fura szim- 
biózisnak lesz még látványos hatása a későbbiekben. 


A POP3-kiszolgáló telepítése 


A POP3-kiszolgálót a megszokott helyen, a Control Panel 
3Add or Remove Programs 3 Add/Remove Windows 
Components dialógusablak segítségével telepíthetjük. 

A komponensek. listájában E-mail Services néven találjuk, 
amit ha bekapcsolunk, a POP3-kiszolgáló mellett rögtön tele- 
píti az SMTP-szolgáltatást is (emlékezzünk, szimbiózis). Az E- 
mail Services alkomponense a POP3 szolgáltatás mellett a 
POP3 Service Web Administration is, amely a kiszolgáló 
rendszergazdai, felügyeleti weboldalához csatolja a POP3 ke- 


zeléséhez szükséges alkomponenseket is. Maga a POP3- 
kiszolgáló természetesen enélkül is működőképes, hiszen az 
MMC-be épülő konzolmodul mindenképpen felkerül a rend- 
szerre. 


Windows Components Wizard Bé 


Windows Components 
You can add or remove component: of Vándowz. 





To add or temove a component, cíck the checkbox. A shaded box means that only 
Battolihe component wál be initaled. To see what ineludedin a component, elek 
Components 

vgjáccerzone: and Utite: 
4 E áppkcakon Server 
7. GR Centbcate Services 
EZ E E-mai Services 
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Dexciption The POP3 service provides e-mal retieval services. The Simple Mal 


Transfer Ptotocol (SMTP) is also installed. 
Detat:, 


Total disk space reguited 29MB 
Space avalable on disk: 1905.9 MB 
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2 A POP3-kiszolgáló , álneve" E-mail Services 


A POP3 felügyeleti MMC konzolja 


Ha a szolgáltatás telepítése után a Start Menü 32 
Administrative Tools 3 POP3 Service menüpontra kattintunk, 
megjelenik a POP3-kiszolgáló felügyeleti eszköze. 









) New Domain 
9) Server Properties 


2) Refresh 


E Egyszerű szolgáltatáshoz egyszerű konzol 


Mielőtt tartományt definiálunk, ellenőrizzük a kiszolgáló álta- 
lános tulajdonságait a Server Properties parancsra kattintva! 


tech.net 








ISERVER2003 Properties a 2]xi 
General ] 
A SERVER2003 
Authentication Method Active Directory Integrated 
Server Port: 110 
Logging Level: Minimum kuzd 





Root Mail Directory: 


€:WnetpubimailrootjMailbox 


Reguire Secure Password Authentication (SPA) for all client 
connections 


(7. Always create an associated user for new maiboxes 


Browse... 





[oo Tette] atot. 7] 


E A POP3-kiszolgáló tulajdonságlapja. A felhasználóazo- 
nosítás módját csak tartomány létrehozása előtt 
módosíthatjuk! 


A dialógusablak legelső kérdése a bejelentkező felhasználók 
azonosításának módja (Authentication Method). Ezt a beállí- 
tást csak akkor módosíthatjuk, ha a POP3-kiszolgálón még 
nem definiáltunk tartományokat. Ebből következik, hogy egy 
POP3-kiszolgáló minden egyes tartománya kötelezően 
ugyanazt az azonosítási módot használja. 


Azonosítási módok 


A kiválasztható azonosítási módok a következők: 

B Local Windows Accounts: a felhasználókat a kiszolgá- 
ló saját felhasználói adatbázisa tartalmazza, minden 
postafiókhoz egy helyi felhasználó tartozik, a bejelent- 
kezéshez a felhasználók a helyi felhasználónevüket és 
jelszavukat használják. Ebben az azonosítási módban a 
felhasználónévnek tartományok között is egyedinek 
kell lennie, tehát nem létezhet ugyanazon a kiszolgá- 
lón usert őfalatrax.hu és usert Ofalatrax2003.hu posta- 
fiók. A Local Windows Accounts azonosítás tartomány- 
vezérlőn nem választható. 

A Active Directory Integrated: a felhasználókat a tarto- 
mányi adatbázis (Active Directory) tartalmazza. Min- 
den postafiókhoz egy tartományi felhasználó tartozik, a 
bejelentkezéshez a felhasználók a tartományi teljes fel- 
használónevüket (például: user1 Ofalatrax.hu) és jelsza- 
vukat használják. Ekkor több tartományban is definiál- 
hatjuk . ugyanazt a felhasználónevet (például 
usert Ofalatrax.hu és user1ofalatrax2003.hu) két kü- 
lönböző felhasználóhoz rendelve is. Az Active 
Directory Integrated azonosítás tartományvezérlőn és 
tartományi tagkiszolgálókon egyaránt választható. 

HA Encrypted Password File: ebben az azonosítási mód- 
ban a felhasználók jelszaván nem a Windows helyi 
adatbázisa, vagy az Active Directory, hanem a felhasz- 
nálók postafiókjában tárolt titkosított fájl tartalmazza. 
Külön felhasználói fiók létrehozására nincs szükség, a 
felhasználók a bejelentkezéshez az e-mail címüket 
(usert Ofalatrax.hu) és a postafiók létrehozásakor 
megadott jelszavukat használják. Ez az azonosítási 
mód tartományvezérlőn, tagkiszolgálón és tartomá- 
nyon kívüli kiszolgálón is választható. 
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A kiszolgáló további beállításai 


A dialógusablak következő mezőjében a kiszolgáló 
portcímét módosíthatjuk (Server Port:), de általában 
ez nem ajánlott, hiszen az ügyfelek a POP3 szabvá- 
nyos portján (TCP 110) keresik a kiszolgálót. A 
Logging level mezőben a naplózás szintjét állíthatjuk be 
(None, azaz nincs naplózás, Minimum, Medium és Maxi- 
mum). A bejegyzések az eseménynaplóba kerülnek. A dialó- 
gusablak alján látható Always create an associated user for 
new mailboxes mező bekapcsolásának annyi a hatása, hogy 
új postafiók létrehozásakor a POP3-kiszolgáló felajánlja az új 
felhasználó létrehozását (kivéve az Encrypted Password File 
azonosítási mód esetén, amikor erre nincs szükség). 


A POP3-kiszolgáló gyökérkönyvtára 
A POP3-kiszolgáló által kezelt e-mail tartományok és posta- 


fiókok egy könyvtárstruktúra képében öltenek testet. A Root 
Mail Directory: mezőben ennek a struktúrának a 


gyökérkönyvtárát határozhatjuk meg, ami alapértelmezésben 
a C: Wnetpub Wnailroot Waailbox lesz. A POP3 szolgáltatás eb- 
ben a könyvtárban minden tartományhoz egy almappát hoz 
létre (a könyvtár neve megegyezik a tartomány nevével). A fel- 
használók postafiókjai a tartományi almappába kerülnek 
(P3 usernév.mbx néven), felhasználók levelei pedig a posta- 
fiók saját mappájába kerülnek. Egy user1Ofalatrax.hu címre 





001 


A fenti könyvtárstuktúrához csak az Administrators csoport tag- 
jai és a Network Service (ennek a nevében fut a POP3- 
kiszolgáló is) fér hozzá. A gyökérkönyvtár elérési útja módosít- 
ható a kiszolgáló tulajdonságlapján, illetve a winpop parancs 
segítségével is, de ha a könyvtárstuktúra már tartalmaz létreho- 
zott tartományokat, postafiókokat és leveleket, a tartalom átvi- 
teléről kézzel kell gondoskodnunk. A Mailbox könyvtárat és al- 
könyvtárait copy helyett move paranccsal kell az új helyre 
mozgatni, mert a jogosultságok mellett fontos szerepe van az 
egyes fájlok tulajdonjogának is. A gyökérkönyvtár beállításait a 








winpop Se 
paranccsal is módosíthatjuk, ez a parancs ráadásul beállítja a 
mappák megfelelő biztonsági beállításait is (a tulajdonjogot 
nem!). A gyökérmappa átállítása után újra kell indítani a 
POP3 Service és az IIS Admin rendszerszolgáltatásokat. 


Secure Password Authentication 


A POP3 az egyik ősprotokoll, ahol a felhasználónév és a jel- 
szó titkosítatlanul utazik a hálózaton. 
ca Telnet 192.168.247.200 


TOK Microsoft Windows POP3 Service Version 1.68 
h read 





IST 
OK 1 messages (785 octets) 
a 785 A 


2 Titkosítatlan jelszó a POP3 bejelentkezésnél 


ü 


Ez bizony erőteljes biztonsági rés (hacsak magát a hálózati for- 
galmat nem titkosítjuk akommunikációs csatorna alatt, például 
IPSec-kel). A bejelentkezés biztonságossá tételének másik mód- 
ja az, ha magát a felhasználóazonosítási protokollt , cseréljük 


E: 


Ai 
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H7 ki", az úgynevezett Clear Text, azaz nyíltjelszavas 
A azonosítás helyett a Secure Password Authentication 


(SPA) metódusra. Az SPA gyakorlatilag integrált Win- 

dows authentikációt használ, azaz a bejelentkezés- 

hez a jól ismert NTLM azonosítást használja fel. Ezt a 
POP3-kiszolgáló tulajdonságlapján található Reguire Secure 
Password Authentication (SPA) for all client connections opció 
bekapcsolásával érhetjük el. Az SPA felhasználóazonosítás so- 
rán a felhasználónév és a jelszó nem utazik titkosítatlanul a há- 
lózaton, a sikeres bejelentkezéshez azonban a levelezőkliens- 
nek is ismernie és használnia kell az SPA-t. 


81192.168.247.200 Properties. 
General , Servers (Connection  Secunty Advanced 
Server Information 
My incoming mail server is a 
Incoming mal (POP3) 
Outgoing mail (SMTP): /192.168.26 
Incoming Mail Server 
Ancount name: user 


Password. ..600000 














v] Remember password 





f TA leg on using Szcure Pass: 


Outgoing Mail Server 











My server reguíres authentication 








2 Az SPA bekapcsolása Outlook Expressben 


A fenti opció bekapcsolása után a levelezőkliens a szerverhez 
való legközelebbi csatlakozáskor kérni fogja a felhasználóne- 
vet és jelszót. Sajnos (szerencsére) ezt információt az Outlook 
Express biztonsági okokból maradandóan nem tárolja, ezért a 
program újraindítása után egy alkalommal mindig meg kell 
majd adni. (Az ábrán látható dialógusablakban megadott fel- 
használónevet és jelszót SPA esetén nem használja). Az igaz- 
sághoz hozzátartozik, hogy az Outlook Express, ha SPA-t 
igénylő kiszolgálóval találkozik, először a felhasználó számí- 
tógépén használt felhasználónévvel és jelszóval próbálkozik, 
és csak akkor kéri a név és jelszó megadását, ha a kiszolgáló 
az előző bejelentkezési próbálkozást visszautasította. 


Az APOP authentikáció 


Az SPA erősen Windows-függő protokoll, ezért az Encrypted 
Password File azonosítási módban működő POP3-kiszol- 
gálóknál az SPA nem használható (akkor ugyanis nincs Win- 
dows felhasználó, akinek a nevét-jelszavát ellenőrizni lehet- 
ne). Ebben az esetben egy másik felhasználóazonosítási pro- 
tokollt, az úgynevezett APOP azonosítást fogadja el a kiszol- 
gáló. Az APOP leírása az Í(RFC1725]-ben található, és tulaj- 
donképpen pofonegyszerű: 






ahud ready, 
BESE érett FEJES TA6TTVATTZT 
tók messages EM octets? 


m 


A felhasználó POP3 bejelentkezése APOP-pal 


Az APOP azonosítást támogató kiszolgáló beköszönő fejlécé- 
ben mindig található egy minden egyes csatlakozáskor egyedi 
azonosító, az ábrán ez például: 


c19085273€server2003.falatrax2003.hus 


Az ügyfél ehhez a fejléchez (kacsacsőrökkel együtt) hozzáfű- 
zi a felhasználó titkosítatlan jelszavát, és az egészből egy 
MDS5 hash-t képez. Ezután a POP3 protokollban kiadja az 


APOP cfelhasználós cMD5-hash: 


parancsot, és már készen is vagyunk. 

A felhasználó jelszava így nem kerül ki a hálózatra, ráadásul 
az MD5 hash is minden alkalommal más és más, hiszen a ki- 
szolgáló a fejlécben mindig változó adatokat küld (ez a 
challenge-response eljárás lényege). 


Az Outlook és az Outlook Express a Secure Password 
Authentication protokollt igen, az APOP parancsot vi- 
szont nem támogatja! (A The Bat! viszont például igen, 
kipróbáltuk, működik.) 


A tartományok létrehozása 


Miután a kiszolgáló tulajdonságait beállítottuk, létrehozhatjuk 
az első tartományunkat. Ehhez a POP3 konzolban kattintsunk 
az Add domain parancsra, a megjelenő dialógusablakban pe- 
dig adjuk meg a kezelni kívánt tartomány nevét. 
Ha a jobb oldali mezőben a tartomány nevére kattintunk, a 
következő parancsokat adhatjuk ki: 
H New Domain - új tartomány létrehozása 
A Lock Domain - a kiválasztott tartomány zárolása (kar- 
bantartási okokból). Ha egy tartomány zárolt, a bejövő 
leveleket elfogadja (a kimenőket pedig természetesen 
kiküldi, hiszen az az SMTP-szolgáltatás dolga), de a fel- 
használói bejelentkezéseket visszautasítja. 
A Delete Domain -— a kiválasztott tartomány törlése. Vi- 
gyázzunk, a tartomány törlése törli az összes postafió- 
kot is, az esetleg bennük található levelekkel együtt! 


A POP3 konzolban létrehozott tartomány megjelenik az 
SMTP-kiszolgálóban is (szimbiózis), Local (custom) típusú tar- 
tományként, amelynek a Drop directory mezője üres. Ez jogos 
is, hiszen a POP3-tartományokba érkező levelek már nem egy 
közös Drop könyvtárba, hanem a megfelelő postafiók könyv- 
tárába kerülnek bele (és ezt az SMTP-kiszolgáló teszi — szim- 
biózis mégegyszer). 


Postafiók létrehozása 


Miután a tartományt létrehoztuk, következhetnek a postafió- 
kok. Kattintsunk a POP3 konzol bal oldali fájában a kiválasz- 
tott tartomány nevére, majd pedig a megjelenő Add 
Mailbox... feliratra! 


B 


1: File Action 





View 


Window Help 
e BBI 


5) POP3 Service 
- (3 SERVER2003 
29 falatrax.hu 


[Add Mailbox 


Mailbox Name: 








[dseri 


[7 Create associated user for this mailbox 


[dodoo000 
[dodo0000 
cane 


2 POP3 postaláda létrehozása 


Password: 


Confirm Password: 





Ha bekattintjuk a Create associated user for this mailbox me- 
zőt, és megadunk egy (pontosabban két) jelszót, a varázsló 
megkísérli létrehozni a felhasználót (a kiszolgáló beállításától 
függően a helyi Windows adatbázisban, vagy az Active 
Directory-ban). Emlékezzünk azonban arra, hogy Local Win- 
dows Accounts azonosítás esetén nem lehet két azonos nevű 
postafiókunk, még különböző tartományokban sem. Az Active 
Directory Integrated azonosítás kiválasztásakor ez a korláto- 
zás nem érvényes, ekkor generálhatunk azonos nevű postafió- 
kokat, ugyanis a felhasználók vagy a teljes felhasználónevük- 
kel (user1 Ofalatrax.hu formátumban), vagy pedig a Pre- 
Windows 2000 Logon Name nevüket használva jelentkeznek 
be. (A másodiknak létrehozott postafiókhoz generált felhasz- 
nálói fiók Pre-Windows 2000 logon neve módosulni fog — a 
000 sorszámot illeszti hozzá a rendszer — így elkerülhető lesz 
a névütközés. Tipp: ha van olyan nevű e-mail tartományunk, 
ami megegyezik a Windows-tartomány nevével, először eb- 
ben a tartományban hozzuk létre a felhasználót, és csak ké- 
sőbb a többiben, különben , The specified user already exists." 
hibaüzenetet kapunk.) Encrypted Password File azonosítás 
esetén a jelszó megadása mindig kötelező, de a postaládához 
felhasználó nem jön létre. 

Akárhogy is tettünk, a postafiók létrehozásának eredménye 
egy dialógusablak, amely tartalmazza a felhasználó bejelent- 
kezéséhez szükséges felhasználónevet (adott esetben lehet, 
hogy két különbözőt, a nyílt jelszavas és az SPA azonosítás 
esetére): 


LETEZETT MENNE 
ij 
The log on information for the new mailbox is defined below. When entering 


their log on information mail client users must use the appropriate version of 
their mailbox name: 


! If vou are using clear text authentication: 
! Account name: user! Gfalatrax.hu 
( Mail server: SERVER2003 
If you are using Secure Password Authentication: 
! Account name; user] 
! Mail server: SERVER2003 


TT Do not show this message again 


xl 


The mailbox was successfully added. 








E A létrehozott postafiók eléréséhez szükséges felhaszná- 
lónevek 





A néhány sorral ezelőtt vázolt esetben előfordulhat, 
hogy a nyíltjelszavas és SPA azonosításhoz használt 
felhasználónév teljesen eltér (például: 
usert Ofalatrax.hu, ugyanakkor SPA-hoz: user1000). 
Ezért a postafiók létrehozásakor mindig figyelmesen 
olvassuk el, jegyezzük fel, és közöljük a felhasználóval a meg- 
jelenített adatokat. 


- 


A postafiók parancsai 


Ha a POP3 konzolban kiválasztunk egy postafiókot, az aláb- 
bi műveletek közül választhatunk: 
A Add Mailbox — új postafiók létrehozása 
A Lock Mailbox — postafiók zárolása. A zárolt postafiókba 
küldött levelek megérkeznek, de a postafiókba történő 
bejelentkezést és a levelek letöltését a kiszolgáló letiltja. 
A Delete Mailbox - a postafiók törlése (vigyázat, ez tör- 
li a felhasználó összes levelét is!) 


Felhasználók és csoportok 


Amikor Windows-, vagy Active Directory-beli felhasználót 
hozunk létre a varázsló segítségével, a felhasználó tulajdon- 
ságlapjának General oldalán a varázsló kitölti a felhasználó- 
hoz tartozó e-mail címet is. Mindig ellenőrizzük azonban, 
hogy ez sikerült-e neki, különben kellemetlen meglepetések 
érhetnek bennünket. 

Amikor a POP3-kiszolgáló nem tartományvezérlőn fut, a va- 
rázsló a létrehozott felhasználókat beleteszi a helyi POP3 
Users csoportba is. Ez a csoport lehetővé teszi, hogy a felhasz- 
nálók elérhessék a POP3-kiszolgálót, ugyanakkor egyéb mó- 
don ne legyen joguk bejelentkezni a kiszolgálóra. Tartomány- 
vezérlők esetén ennek a csoportnak nincs szerepe, hiszen oda 
a tartományi felhasználók egyébként sem léphetnek be. 

A felhasználó jelszavát több módon is megváltoztathatjuk: 
egyrészt, Local Windows Accounts és Active Directory 
Integrated azonosítás esetén a Windowsban már megszokott 
módon, másrészt pedig, bármikor a winpop paranccsal: 


winpop changepwd cuseredomain; cúj jelszóz 


Kvóták és korlátozások 

A felhasználóknak küldött terjedelmes e-mailek hamar meg- 
töltik a rendelkezésükre álló lemezterületet. A postafiók mére- 
tét ezért a Windows beépített kvótarendszerének segítségével 
korlátozhatjuk (amennyiben a Mailbox gyökérkönyvtár NTFS 
partíción található, hiszen kvóta is csak ott létezik). Egy NTFS 
partíción minden egyes fájlnak és mappának van tulajdonosa 
(ez általában az a felhasználó, aki létrehozta a fájlt). A kvóta- 
rendszer pedig a fájlok tulajdonjoga alapján számolja és 
összegzi az egyes felhasználók által használt lemezterületet, 
és ha a használt terület mérete eléri az előre beállított határt, 
a Windows a lemezre írást megakadályozza (kivéve az 
Administrators csoport tagságát, akikre nem vonatkoznak a 
kvóta korlátozásai). 

A beérkező leveleket azonban nem a felhasználó, hanem ma- 
ga a szolgáltatás helyezi el a postafiókokban, így elvileg a 
levelek tulajdonosa is a Network Service lenne — ha nem mó- 
dosítaná a fájlok tulajdonosának beállításait a megfelelő mó- 
don. Ehhez a felhasználó belső biztonsági azonosítójára 
(Security Identifier, SID) van szükség, amelyet a felhasználó 
postaládájában, a Ouota nevű fájlban tárol a rendszer. Amikor 
egy levél érkezik, a kiszolgáló a megfelelő felhasználó posta- 
ládájában található Ouota fájlból kiolvassa a felhasználó SID- 
jét, és beállítja a létrehozott fájlon. 


- 
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- Levelezőszolgáltatások a Windows Server 2003-ban: 


Internet Information Services 6.0 


20 


A Ouota fájl Local Windows Accounts és Active 
w Directory Integrated azonosítás esetén a postafiók 
] létrehozásakor automatikusan létrejön. Az Encrypted 
Password File azonosítás használatakor azonban 
nincs felhasználó, így nincs kvótafájl sem. 






Pemissions [/Aúdtng . Over ] Elfectve Peission ] 
"You can take or assign owmnership of tés object f you have the reguted permission 


Curent owner ol thiz tem 
usert (usert falatra] 


Change gyner tor 





E szara FALATASZA zata] 
KÜ Adrriristtators (FALATRAXKZOOZVA dmirástrators]) 


E A postafiókban tárolt levelek tulajdonosa maga a fel- 
használó - így érvényesülhet rá a kvóta is 


Ha mégis szeretnénk kihasználni a kvótarendszer előnyeit, 
magunknak kell létrehozni a felhasználókat, és elkészíteni a 
postafiókokban a megfelelő Ouota fájlt. Ehhez a winpop pa- 
rancsot használhatjuk: 





125 okod Be Mze Ta 


például: 





 winp 
B JT EGZAbOLU TE év ég zo z 

A parancs futtatása után minden, az adott postafiókba beérkező 
levél a felhasználó kvótáját terheli. (Ne keverjük össze a posta- 
fiók ,felhasználóját" a kvótázáshoz használt felhasználóval. A 
fenti művelet után az Administrator felhasználónak továbbra 
sem lesz joga bejelentkezni a user1 Ofalatrax.hu postafiókba.) 
A kvótázást azon a meghajtón kell bekapcsolni, amin a posta- 
fiókok gyökérkönyvtára szerepel (éppen ezért érdemes a pos- 
tafiókoknak egy külön partíciót fenntartani). A meghajtó tulaj- 
donságlapjának Ouota oldalán válasszuk az Enable guota 
management és a Deny disk space to users exceeding guota 
limit opciókat, majd állítsuk be az alapértelmezett kvótamére- 
tet. Az Apply gombra kattintva a kvótarendszer bekapcsol, és 
elkezdi felépíteni a kvótaadatbázist (a közlekedési lámpa ek- 
kor sárgán világít). Amikor zöldre vált, a kvótaadatbázis elké- 
szült, és a Ouota Entries... gombra kattintva meg is tekinthet- 
jük. Az egyes bejegyzéseken jobb gombbal kattintva felhasz- 
nálónként is módosíthatjuk a kvótabeállításokat. A Status osz- 
lopban láthatjuk, hogy az egyes felhasználók milyen viszony- 
ban vannak a beállított határokkal. 


(ETL ETETETT ZTE 2 
árl PC Teát tatár: 12 öráárg: "Új 
I Securty I Shadow Copiez. Ouota 


ÍZ sa bekamlatyemi te 


FF. Enable gucta management 
l [7 Deny dítk space to urets exoeedng guota ímit 


2 Ouota Entries for Local Disk (CJ BE 


vot Edt View Heb 




















DxXf-7G 
ma Tema — Ttsgentisse Azaz szá] Gustalmz 
! jábovelet úsez userzGflearTa 12.06 me 1018 
! Bor user — úseriGfalatran hu 1138 1018 
! 2) ax NT AUTKORITYILOCAL SERVICE 4988 1018 
Y9or FALATRAXZOOZÍDOMÁIN Admns 14B 1048 
or FALATRAXZOOZ  Administrator 6x8 1048 
Do BUNLTIMYAdmítstrators Zz4GB Nola 


E Ha engedélyeztük a kvótázást, a kvótabejegyzéseknél 
jól látszik a postafiókok által felhasznált terület 


Ha egy postafiók megtelt, a beérkező levelet a kiszolgáló nem 
kézbesíti, erről a tényről pedig Non-Delivery Report (NDR) 
üzenetet küld a feladónak. 


Tartományi kvótázás 

A most leírtak alapján a kvóta minden egyes felhasználóra kü- 
lön-külön érvényesül. Azonban megtehetjük, hogy ugyanazt a 
Windows-felhasználót egynél több, sőt, akár teljes tarto- 
mánnyi felhasználóhoz is hozzárendelhetjük a winpop segít- 
ségével (vagy, ha a kiválasztott felhasználó postafiókjából a 
Ouota fájlt kézzel bemásoljuk a többi felhasználó postafiókjá- 
ba). Ekkor a kvóta egyidejűleg mindenkire érvényesül majd, 
hiszen mindenkinek ugyanazzal a SID-del jönnek létre a beér- 
kező leveleket tartalmazó fájlok. 


Áttérés a felhasználóazonosítási üzemmódok között 


A felhasználóazonosítási üzemmódok között két útvonalon 
biztosít" átjárást a POP3-kiszolgáló. Az első, ha Local Win- 
dows Accounts azonosítással futó POP3-kiszolgáló , alatt" tar- 
tományvezérlőt telepítünk a számítógépre. Ekkor — definíció 
szerint — a Local Windows Accounts azonosítási mód megszű- 
nik. Az áttérésnek az a sajnálatos útja, hogy a tartományvezér- 
lő telepítése előtt törölnünk kell a POP3-kiszolgáló minden 
postafiókját és a definiált tattományokat, majd a tartományve- 
zérlő telepítése és az azonosítási mód átállítása után újra lét- 
re kell hozni azokat. 

A másik átjárás barátságosabb: ennek során az Encrypted 
Password File azonosítási módot váltja fel az Active Directory 
Integrated azonosítás. Ekkor — bár a postafiókokat az üzem- 
módváltás miatt itt is létre kell majd hozni — a meglévő POP3 
felhasználókat jelszavastul , be lehet emelni" a címtárba, a kö- 
vetkező parancs segítségével: 


winpop migrateToAD cuserédomain: — HEZ 
SMTP LDAP Routing 


Az előző számban az SMTP-kiszolgálóról volt szó, de a 
SMTP-szolgáltatás egy opcióját tudatosan későbbre hagytuk. 
Ez az LDAP Routing néven ismert funkció, ami a levelek pos- 
tázásához képes felhasználni a különféle (Active Directory, 
Exchange, stb.) címtárakban tárolt információkat. Egészen 
pontosan e-mail terjesztési listákról (Distribution List) van szó, 
ami saját e-mail címmel rendelkezik, és minden erre a címre 
küldött levelet minden csoporttag-felhasználó megkap. Nyil- 
vánvaló hogy ez az SMTP-kiszolgáló feladata, de addig, míg a 
postafiókok kezelése (hála a POP3-nak) nem volt megoldva, 
ennek a funkciónak nem volt sok értelme. No de most! 
Tegyük fel, hogy adott egy e-mail tartomány, Active Directory 
alapú felhasználóazonosítással. Benne három felhasználó, 
név-(lemailcím-) szerint administratorOfalatrax.hu, 
usert Ofalatrax.hu, user2falatrax.hu. Egy szép napon valaki 
a falatrax.hu teljes ügyfélkörének szeretne levelet küldeni, 
mondjuk úgy, hogy a címzetthez mindenkiGrfalatrax.hu-t ír, a 
többit pedig rábízza a kiszolgálóra. Az eredmény — hiszen a 
fenti postafiók nem létezik — egy NDR lesz, miszerint a min- 
denkiGfalatrax.hu címre nem kézbesíthető levél. 

Hozzunk most létre az Active Directory-ban egy terjesztési 
csoportot (Distribution Group), és tagjainak vegyük fel a fenti 
három felhasználót! 











Í 
li Mindenki Properties 


General ] Members ] Member Of] Managed By] Object) Security ) 


e Mindenki 


Group name (pre-windows 2000) Mindenki 
Desciiption: 


E-mait mindenkiéfalatrax hd 


Group scope ti Ir Group type 
(7 Domain local If € Sec 

C Global GC Distribution 
C Ur 


2 Terjesztési csoport az Active Directory-ban 


Ne felejtsük el beállítani a csoport e-mail címét! Ezután indít- 
suk el az Internet Information Services Manager MMC kon- 
zolt, majd nyissuk meg a Default SMTP Virtual Server tulaj- 
donságlapját! Ennek LDAP Routing oldalán lehet engedélyez- 
ni a címtárhoz való kapcsolódást. A beállítások a következők: 

A Enable LDAP Routing — az LDAP Routing engedélye- 
zése 

A Server — a címtárkiszolgáló neve 

H Schema - a címtár típusa, lehet Active Directory, Site 
Server Membership Directory és Exchange LDAP 
Service 

A Binding — a kapcsolódáshoz használt bejelentkezési 
adatok. Lehet Anonymous, Service account (ekkor a 
Network Service szolgáltatás nevében kapcsolódik), 
plain text (nyílt szöveges), és Windows SSPI. Utóbbi 
két esetben meg kell adnunk a használni kívánt tarto- 
mányt, felhasználónevet és jelszót. 

A Base - a címtárbeli keresés kiindulópontja. Lehet pél- 
dául a tartomány neve, de ha az objektumainkat a 
címtár egy jól definiált pontjára (például szervezeti 
egységbe) tömörítettük, itt megadhatjuk azt is. Ez fel- 
gyorsítja a keresést. 








Default SMTP Virtual Server Properties 2 
General ] Access ] Messages ] Delivery LDAP Routing ] Security ] 
FE i 

Server 

focalhost 

Schema: 

Active Dírectory 7 
Binding: 

Service account s 

Dom 


Baszword 
Base 


JOCsfalatrax2003 DC-hu 





Cancel poly Help 





8 Az LDAP kapcsolódási pont beállításai 


Az IIS Admin szolgáltatás újraindítása után az SMTP- 
kiszolgáló már ellenőrzi a címeket a címtárban, elfogadja és 
kifejti (kézbesíti) a terjesztési listák címére (például a minden- 
kifalatrax.hu címre) érkező leveleket is. 


Egy trükk a végére: aliasok 


"Hivatalosan" nincs mód arra, hogy egy postafiókhoz több e- 
mail címet rendeljünk, holott ez az általános gyakorlatban 
bevett szokás. Mégis van megoldás, ami az NTFS fájlrendszer 
egy ritkán használt funkciójára, a hard link-re alapul. Mint 
tudjuk, a szolgáltatás a beérkező leveleket a könyvtárstruktú- 
ra segítségével szortírozza, helyezi el a megfelelő postafiók- 
ba. Az NTFS hard link-nek köszönhetően megtehetjük, hogy 
olyan elágazási pontot (junction point) hozunk létre, ami más 
néven, de egy adott könyvtárra mutat. Az ötlet egyszerű: ha 
egy felhasználó postafiókja a P3 usernév.mbx könyvtárban 
található, hozzunk létre egy P3 másiknév.mbx mappát, ami 
fizikailag ugyanerre a könyvtárra mutat. Ehhez a 
(rktools2003] címről letölthető Windows 2003 Resource Kit 
Tools egyik segédprogramját, a linkd.exe-t használhatjuk. Te- 
gyük fel például, hogy az administratorOfalatrax.hu posta- 
fiókhoz szeretnénk felvenni mondjuk a 
postmasterOfalatrax.hu címet is. Ehhez először hozzuk létre 
a szokásos módon az administrator postafiókját, majd men- 
jünk be a falatrax.hu könyvtárba és adjuk ki a következő pa- 
rancsot: 


linkda P3 postmaster.mbx P3 administrator.mbx 


Ex Command Prompt 


:NInetpublmailrootNMMailboxNfalatrax.hujdir 
Volume in drive C has no label. 
Volune Serial Number is 20E8-315A 


Directory of C:XInetpubNmailrootNMMailboxNfalatrax.hu 








903. 97. 08. 2 

083. 87. 08. 2 

903. 07. 08. 2; 

083. 97. 08. 2 

903. 97. 08. 2 P 

043. 07. 08. 2 XDIR2 P3-user2.nbx 
0 Filecs B bytes 
6 Dircs) 1 992 327 168 bytes free 


:NinetpubtmailrootMMailboxtfalatrax.hud 


A hard linket felismerhetjük a JUNCTION-; feliratról. 


Ekkor látszólag létrejön egy P3 postmaster.mbx mappa, ami 
valójában fizikailag a P3. administrator.mbx könyvtárra mutat. 
Ennek köszönhetően a postmasterGfalatrax.hu címre beérke- 
ző levelek az Administrator postafiókjába potyognak majd be. 
A leveleket letölteni, bejelentkezni természetesen változatla- 
nul, az Administrator felhasználóval kell és lehetséges. Ha tö- 
rölni szeretnénk a felhasználót, előbb töröljük a linket, külön- 
ben az a semmibe fog mutatni: 





linkd P3 postmaster.mbx /d 


Fülöp Miklós 
mickEinetcom.hu 


A cikkben szereplő URL 





a http://technet.netacade 
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" Mi van egy tanúsítványban? / 


Tanúsítványkiadók a Windowsban 


2e 


Tanúsítvánukiadók a 
Mindomwsban 


Mi van egy tanúsítványban? 


Cikkünk következő részében először az X.509 digitális tanúsítványok mélyreható boncolgatására kerül 
sor, majd visszatérünk a Windows Server 2003, Enterprise Edition tanúsítványkiadójának újdonságaira. 


A tanúsítványok mezői 


A PKI tanúsítványok digitálisan aláírt adatcsomagok, ame- 
lyek a tulajdonos publikus kulcsán és a tulajdonos adatain 
kívül sok más információt is tartalmaznak. Ezeket az infor- 
mációkat a tanúsítványt felhasználó és kezelő alkalmazások 
(beleértve magát a Windows operációs rendszert) kezelik és 
dolgozzák fel. 

Ha egy tanúsítványt megnyitunk (kettőt kattintunk rá), a 
Certificate dialógusablak jelenik meg. A dialógusablak első 
(General) oldalán a tanúsítvány legfontosabb jellemzőit (tulaj- 
donos, kiadó, érvényességi idő, privát kulcs megléte — vigyá- 
Zat ez nem azt jelenti hogy a tanúsítvány tartalmazná a privát 
kulcsot!) sorolja fel a rendszer. A részletes adatok a Details ol- 
dalon találhatók. 

A tanúsítványok felépítését (és mezőit) az Í(RFC2459] szab- 
vány írja le bitekig történő részletességgel. Ezeket a mezőket 
mutatjuk be a következő oldalakon. 


[eddig d 


General Details ] certification Path] 


Show; [Alla be 
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Field. value 

Elíissuer Falatrax CA, falatrax2003, hu 
(Elvalid from 2003. június 29. 20:36:17 
Elvalid to 2004. június 28. 20:36:17 
(Elsubject administrator€falatrax2003.hu, Ar 
Elpublic key RSA (2048 Bits) 

[Fákey Usage Digital Signature, Key Enciphermen 


[EZ] SMIME Capabilíties (1]SMIME Capabilty: Object ID-1. v] 


: al 


z administratoráfalatrax2003.hu 
Administrator 









Edit Properties. , . ] Copy to File... 








d Az X.509 tanúsítvány mezői 


A tanúsítványok mezői három csoportba sorolhatók. A mezők 
általános információk (ezek megléte minden tanúsítványban 
kötelező), bővítmények, és kritikus bővítmények lehetnek. A 


bővítményeket zöld nyíl, a kritikus bővítményeket sárga, fel- 
kiáltójelet tartalmazó háromszög jelzi. Ha egy alkalmazás egy 
tanúsítványban kritikus bővítményt , vár", de az nincs jelen, 
vagy a tanúsítvány olyan kritikus bővítményt tartalmaz, amit a 
Windows nem ismer fel, a tanúsítvány érvénytelennek számít. 
Lássuk először az általános mezőket (Version 1 Fields) sorban: 


A Version: a tanúsítvány X.509 verziója. Az RFC 2459 és 
a Windows a v3-as tanúsítványverziót használja. 

A Serial Number: a tanúsítvány sorozatszáma. CA-n be- 
lül egyedi, minden kiadott tanúsítványt egyértelműen 
azonosít. Ez az azonosító szerepel a visszavont tanúsít- 
ványok listájában is. 

A Signature Algorithm: a tanúsítvány digitális aláírásához 
használt algoritmus 

A Issuer: a tanúsítványt kiadó szervezet (CA) neve (X.501 
formátumban) 

A Valid from:, Valid to: a tanúsítvány érvényességi ideje 
(tól-ig). 

A Subject: a tanúsítvány (publikus kulcs) tulajdonosának 
neve (X.500 formátumban). Ez a mező lehet üres, ha a 
tulajdonos nem CA, és ha a tanúsítvány tartalmazza a 
Subject Alternative Name mezőt. (A tanúsítványok tu- 
lajdonosának ellenőrzésekor a rendszer mindig mind- 
két jellemző értékét ellenőrzi.) 

A Public Key: a publikus kulcsot és a titkosítási algoritmus 
azonosítóját tartalmazó mező ítehát nem bitről-bitre a 
publikus kulcs!) 


Eddig a kötelező (v1 verziójú tanúsítványokban definiált) me- 
zők. A következő lista a bővítménymezőket tartalmazza. Ezek 
a bővítmények csak v3 verziójú tanúsítványban szerepelhet- 
nek, és jelenlétük sem mindig kötelező. 


A Subject Alternative Name: a tulajdonos egyéb nevei. 
Ebben a mezőben a tanúsítvány tulajdonosának egyéb 
azonosítói találhatók. Egy azonosító lehet e-mail cím 
(illetve User Principal Name, a felhasználó Windows 
2000 tartomány-beli, ,e-mailcímszerű" neve), IP-cím, 
DNS-név és Uniform Resource Identifier (UR. Min- 
den esetben, amikor bárki a tanúsítvány tulajdonosára 
vonatkozó adatokat ellenőriz, vagy dolgoz fel, a 
Subject mezőben található X.500-formátumú név mel- 
lett kezelnie kell a Subject Alternative Name mező tar- 
talmát is. 

A Key Usage: a tanúsítványban található kulcs felhaszná- 
lási területei. Az alábbiak kombinációja lehet (ha nincs 





megadva, a felhasználási területeket nem korlátozzuk): 
Digital Signature (digitális aláírás), Non Repudiation 
(digitális aláírás — letagadhatatlanság biztosítása), Key 
Encipherment  (kulcstitkosítás), Data Encipherment 
(adattitkosítás), Key Agreement (kulcsmenedzsment — 
pl. Diffie-Hellmann protokollhoz), Certificate Signing 
(tanúsítványok digitális aláírása — csak CA tanúsítvá- 
nyokban lehet jelen), CRL Signing (tanúsítvány-vissza- 
vonási lista digitális aláírása), Encipher Only (csak tit- 
kosítás), Decipher Only (csak dekódolás) 

H SMIME Capabilities: titkosítási algoritmusok azonosítói 
(OID-K), amelyekhez a tanúsítvány (és a benne tárolt 
kulcs) felhasználható. Egy Windows 2003 CA által 
kiadott tanúsítvány az alábbi OID-ket tartalmazza: 
1.2.840.113549.3.2 (RC2-CBC), 1.2.840.113549.3.4 
(RC4), 1.3.14.3.2.7 (DES-CBC), 1.2.840.113549.3.7 
(DES-EDE3-CBC). Ezt a mezőt az S/MIME v2 specifiká- 
ciójában (RFC2311] találjuk meg először. Az alkalma- 
zások egyelőre nem várják el a mező meglétét (a Win- 
dows 2000 CA-ja által kiadott tanúsítványokban ez a 
mező például még nem is szerepel). 


Object Identifier (OID): Azonosítórendszer, amelyet világ- 
szerte különböző célokra használnak. Az adatbázist az ITU, 
az IANA, az ANSI és más regisztrátorok kezelik. Az 
azonosítórendszer hierarchikus, a hierarchia szintjeit az azo- 
nosítóban található pontok különítik el. (Az Internet OID-je 
például 1.3.6.1, a titkosítási algoritmusoké például 
1.2.840.113549.3). Saját OID-t cégek is kaphatnak, azokat 
tovább , bontva" (azaz bővítve) bárki saját OID-ket is generál- 
hat. A Microsoft egyik OID-je például 1.3.6.1.4.1.311 — min- 
den OID, ami így kezdődik, a Microsoft ,sajátja". A 
IKB287547]-es tudásbáziscikkben sok microsoftos, kriptográ- 
fiai területen használt, ,belső" OID leírását megtaláljuk. 

MA Subject Key Identifier: A tanúsítványban található pub- 
likus kulcs egyedi azonosítója (általában a publikus 
kulcsból készült SHA-1 hash). Ezt az adatot általában a 
tanúsítványlánc felépítésében használjuk (az Authority 
Key Identifier mezővel együtt). 

A Authority Key Identifier: A tanúsítvány digitális aláírásá- 
hoz használt privát kulcs publikus párjának egyedi 
azonosítója (azaz, a tanúsítványt kiadó CA publikus 
kulcsából készült SHA-1 hash), Egy tanúsítványban ta- 
lálható AKI érték megegyezik a kiadó CA tanúsítványá- 
ban található SKI mező értékével. 

MA Certificate Template Name/lnformation: a tanúsítvány 
kiadásához használt tanúsítványsablon neve (Windows 
2003 CA esetén verziószáma is). Ez a mező nem szere- 
pel az (RFC2459] specifikációban. 

HA CRL Distribution Points: a tanúsítványt kiadó CA által 
közzétett tanúsítványvisszavonási listák (CRL-ek) eléré- 
si útja(i). Értéke egy vagy több URI (Uniform Resource 
Identifier), amelyek lehetnek Idap:// (X.509 címtárbeli), 
http://, ftp://, file:// (fájlrendszerben közvetlenül elérhe- 
tő) címek. Az alkalmazások az itt található információ 
segítségével tölthetik le a CRL-t, és ellenőrizhetik a ta- 
núsítvány visszavonási státuszát. A mező megléte nem 
kötelező, de ajánlott. 


Magyar viszonyok: A cikk írásának pillanatában (2003. június 
29.) két, HIF által minősített tanúsítványkiadó szolgáltatást 


nyújtó céget, a NetLock Kft-t [INetLock], és a MÁV 
Informatika Kft-t MAVCAI , teszteltük". 

A NetLock által kiadott teszttanúsítványok nem tar- 
talmazzák a CRL Distribution Point mezőt. (Rákér- 
deztünk: ennek oka, hogy elég sok alkalmazás egy- 
szerűen lefagy, ha nem éri el a CDP-t -— márpedig belső, vé- 
dett hálózatról ennek nem is kicsi az esélye. A NetLock ezért 
átmeneti megoldásként — amíg az alkalmazások ,ki nem ja- 
vulnak" -— egyrészt lehetővé teszi a INetLockCRL] címről az 
aktuális CRL-ek letöltését, amelyek importálhatók a rendszer- 
be, másrészt a tanúsítvány kérhető kitöltött CDP-vel is.) 

A MÁV Informatika CA-jától kapott teszttanúsítvány teljes és 
érvényes CRL hivatkozást tartalmazott. 


A Enhanced Key Usage: Kiterjesztett kulcshasználati in- 
formációk. Kriptográfiai alkalmazások OID-it találjuk 
itt, amelyek esetén a tanúsítvány (és a benne található 
kulcs) alkalmazható. Ez a mező nem szerepel az 
IRFC24591-es specifikációban, viszont létfontosságú a 
Windows 2000-alapú rendszerekben. A Windows 
2003 CA már képes az Application Policies mező ke- 
zelésére is, amely ugyanezeket a feladatokat látja el (és 
szerepel is az IRFC2459]-ben) és idővel teljesen felvált- 
ja majd az EKU-t.. 


Ebben a mezőben olvasható OID-k határozzák 
meg tehát azt, hogy egy tanúsítvány mire használ- 
ható. Mielőtt egy alkalmazás felhasználna egy ta- 
núsítványt, ellenőrzi ennek a mezőnek a tartal- 
mát. Néhány példa: Client Authentication 
(Ügyfélazonosítás, 1.3.6.1.5.5.7.3.2), Secure 
Email (Biztonságos levelezés, 1.3.6.1.5.5.7.3.4), 
Smart Card Logon (Bejelentkezés Smart Card-dal, 
1.3.6.1.4.1.311.20.2.2), Encrypting File System 
(1.3.6.1.4.1.311.10.3.4), File Recovery (EFS fájlok 
helyreállítása, 1.3.6.1.4.1.311.10.3.4.1), Server 
Authentication (Kiszolgálóazonosítás, 
1.3.6.1.5.5.7.3.1), stb. Ha nincs EKU mező, a ta- 
núsítvány bármilyen területen felhasználható, 
amit a Key Usage mező engedélyez. 


A Application Policies: ugyanarra a célra való, mint a 
fent bemutatott EKU mező. A Windows Server 2003, 
Enterprise Edition CA szolgáltatása által kiadott tanúsít- 
ványok már tartalmazhatják ezt a mezőt. A Windows 
Server 2003 kompatibilitási okok miatt támogatja az 
EKU használatát is, de ha az AP mező megtalálható, az 
EKU mező tartalma irreveláns (a kiadott tanúsítványok- 
ban egyébként az EKU és az AP mező tartalma 
megegyezik — ha van). A meglévőek mellett saját 
Application Policy-t is létrtehozhatunk (saját OID-vel). 

A Certificate Policies: más néven Issuance Policies: a ta- 
núsítványok kiadásával kapcsolatos eljárás ,biztonsági 
szintjét" meghatározó érték (csak Windows Server 
2003 alatt érvényes). Ez biztonsági szint (illetve a hoz- 
zájuk tartozó eljárások) relatív fogalmak — jelentésük a 
felhasználási környezettől függően más és más lehet. A 
Microsoft négy szintet definiál: ezek közül három a 
Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400) — 
alacsony, Medium Assurance 
(1.3.6.1.4.1.311.21.8.x.y.z.1.401) — közepes, High 
Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402) magas 
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biztonsági szint. Az x,y.z érték minden Active 

Directory erdőben egyedileg, véletlenszerűen gene- 

rált érték. Ezzel is biztosítható, hogy az egyes szintek- 

hez hozzárendelt eljárási rend , helyi" jellegű, más 

rendszerekkel automatikusan össze nem egyeztethe- 
tő. (Az ilyen párosításra egyébként van mód, de erről a 
következő részben lesz szó.) Az előre definiált szintek 
mellett saját értékeket is létrehozhatunk (ismét csak sa- 
ját OID-vel azonosítva). 


A biztonsági szint kikényszerítése is csak egyetlen ponton 
van kidolgozva ,gyárilag": minden CA csak olyan tanúsítvá- 
nyokat adhat ki, amelyekre a CA saját tanúsítványában talál- 
ható Certificate Policies mező tartalma feljogosítja. Ha a CA 
tanúsítványában ez a mező nem szerepel, nincs korlátozás; 
ugyanezt jelenti, ha a CA tanúsítványában az előre definiált 
negyedik, AII Issuance (2.5.29.32.0) érték szerepel. 


H Basic Constraints: a mező értéke határozza meg, 
hogy a tanúsítvány végfelhasználó, vagy tanúsítvány- 
kiadó tanúsítványa-e. (A Windows is ebből dönti el, 
hogy egy importált tanúsítványt automatikusan a ta- 
núsítványtár Personal vagy a Trusted illetve 
Intermediate Certification Authorities mappájába he- 
lyezi el). Ha a Basic Constraints mezőben a Subject 
Type jellemző értéke CA, tanúsítványkiadói tanúsít- 
vánnyal van dolgunk. A mező másik, Path Length 
Constraint értéke azt határozza meg, hogy a tanúsít- 
vány tulajdonosa (ha CA), adhat-e ki gyermek CA-k 
részére tanúsítványt, vagy sem. Erre is visszatérünk 
még a következő részben, egyelőre legyen elég annyi, 
hogy a jellemző 0 értéke azt eredményezi, hogy a CA 
csak végfelhasználókat szolgálhat ki. Ha ez a mező 
egy tanúsítványban megtalálható, mindig kritikus. 


Ezzel végére értünk a ,hétköznapi" tanúsítványok mezői 
bemutatásának. Van még néhány fontos mező, ami tanúsít- 
ványkiadók tanúsítványai esetén lesz majd érdekes — a követ- 
kező részben. Addig is, két mező maradt még ismeretlen, 
amelyek bár az [RFC2459]-ben nem szerepelnek, mégis 
sokszor találkozunk velük, ez pedig a tanúsítvány ,ujjlenyo- 
mata", 


A Thumbprint Algorithm: a tanúsítvány egyedi azonosí- 
tójának (,ujjlenyomatának") elkészítéséhez használt 
algoritmus azonosítója 

mA Thumbprint: a tanúsítvány egyedi azonosítója (ennek 
alapján bármely tanúsítvány egyértelműen azonosít- 
ható — ne keverjük össze a sorozatszámmal, ami csak 
CA-n belül egyedi!) 


A v2-es tanúsítványsablonok jellemzői 


Az előző részben elkezdtük a v2-es (azaz írható és módosít- 
ható) tanúsítványsablonok beállításainak bemutatását. Az 
Active Directory-beli sablonok tulajdonságlapjának Reguest 
Handling oldalán találunk egy beállítást, amely a Do the 
following when the subject is enrolled... névre hallgat. Az op- 
ciók a privát kulcs kezelését, illetve az automatikus tanúsít- 
ványkérés működését hangolják: 


AA Enroll subject without reguiring any user input: tanú- 
sítvány kiadása felhasználói beavatkozás nélkül 


JA Prompt the user during enrollment: a tanúsítvány kéré- 
se előtt a felhasználót kis felugró buborékablakban ér- 
tesítjük, hogy automatikus tanúsítványkérés kezdődik 

TA Prompt... and reguire user input when the private key 
is used: automatikus tanúsítványkérés esetén értesíti a 
felhasználót és bekapcsolja a privát kulcs megerősített 
védelmét 


A Subject Name oldalon a tulajdonos nevével (most már tud- 
juk, hogy a tanúsítvány Subject és Subject Alternative Name 
mezőjével) kapcsolatos opciókat találjuk: 


Eirrtatezá ati i HE XI 


Issuance Reguirements l Superseded Templates ] Extensions ] Security l 
General ] Reguest Handling Subject Name 


C Supply in the reguest 
Select this option to allow a variety of subject name formats or if you do 
not have access to the domain of which the subject is a member. 
Autoenrollment is not allowed if you choose this option. 

(7 Build from this Active Directory information ——— 


! 
Select this option to enforce consistency among subject names and to 
simplify certificate administration. ! 

! 


Subject name format: 


Fully distinguished name e ] 


[7 Include e-mail name in subject name 


Include this information in alternate subject name: 
[7 E-mail name 

T DNS name 

[7 User prinicipal name (UPN) 

T Service principal name (S$PN) 








Cancel 4pply 





E A tanúsítvány tulajdonosának adatai 


A Supply in the reguest opció esetén minden adatot a tanú- 
sítványkérésben küldenek el nekünk. Ami számunkra igazán 
érdekes, az a Build írom this Active Directory information - 
azaz, amikor az adatok a címtárból származnak. Az első 
beállítási lehetőség a Subject name format. Itt meghatároz- 
hatjuk, hogy a tanúsítvány Subject mezőjébe a tulajdonos tel- 
jes, Active Directory-beli LDAP neve (pl. CN-Administrator, 
CN-Users, DC-falatrax2003, DC-hu - azaz a Fully 
distinguished name), a rövid neve (CN-Administrator — azaz 
a Common Name), vagy semmi (None) sem kerüljön. (Gon- 
doljunk arra, hogy ezt a szabvány megengedi, ha a Subject 
Alternative Name mező ki van töltve). Ha akarjuk, itt megha- 
tározhatjuk azt is, hogy a felhasználó e-mail címe bekerül- 
jön-e a Subject mezőbe. 


A következő opciókkal azt határozhatjuk meg, hogy mi kerül- 
jön a Subject Alternative Name mezőbe: e-mail cím, DNS- 
név, User Principal Name (UPN) vagy Service Principal 
Name (SPN). Vigyázzunk, hogy e-mail címe csak felhaszná- 
lónak, DNS-neve pedig csak számítógépnek van. Ha a tanú- 
sítványsablonban ezeket bekapcsoljuk, és a tulajdonos nem 
rendelkezik valamelyik adattal (az e-mail cím a felhasználó 
Active Directory-beli objektumának General oldalán találha- 
tó E-mail mező tartalma), a Policy Agent visszautasítja a ta- 
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núsítvány kiadását. Erről a Certificate Authority konzol Failed 
Reguest listájából is értesülhetünk. 

A tanúsítványsablon  tulajdonságlapjának  Superseded 
Templates oldalán a tanúsítványsablon által érvénytelenített 
más tanúsítványsablonok találhatók. Az itt felsorolt tanúsítvá- 
nyok helyett a CA már az új típusú tanúsítványt fogja kiadni. 
Az Extensions oldalon a tanúsítványbővítmények beállításait 
látjuk. 


SuperUser Pr 21xI 


General] RegvestHandíng — ] 0 SubiectName  ] 
Issuance Reguirements ]  Superseded Templates  Extensions ) Security ] 


To modily an extension, select it, and then click Edit. 


Edit Application Policies EXCEREIŐI 21xi 


An application policy defines how a certificate can be 
used 


Extensions included in this template: 





r—] Certificate Teraplate Information 
]issuance Policies 





E]keyUsage Application policies: 
Enciypting File System 
Secure E 
SuperlUser Tevekenyseg 
Desciiption of Application Policies: 


Add Edt Remove 


TT Make this extenrion critical 


Lo] eres ] 











B A tanúsítványsablon bővítményeinek beállításai 


Itt beállíthatjuk, hogy a sablonból készült tanúsítvány milyen 
Key Usage, Application Policies illetve Issuance Policies bő- 
vítményeket tartalmazzon. Ha az Issuance és Application 
Policies sor kiválasztása után az Edit... gombra kattintunk, 
megjelenik a bővítmény saját ablaka, ahova felvehetjük az 
előre definiált bejegyzéseket (jusson eszünkbe, hogy az 
Application Policies bővítmény tartalmával határozzuk meg a 
tanúsítvány Extended Key Usage mezőjének értékét is). Ha az 
Add... gombra kattintunk, kiválaszthatjuk a listához hozzáad- 
ni kívánt OID-ket, sőt a megjelenő ablak New... gombjára 
kattintva új elemeket is hozhatunk létre. Ehhez névre és OID- 
re lesz szükségünk, de az OID mezőben szerencsére a Win- 
dows automatikusan felkínál egy garantáltan egyedi (az 
Issuance Policy leírásánál bemutatott módon generált), vélet- 
lenszerű OID-t, amit használhatunk, ha akarunk. Az ábrán lát- 
ható sablonba így kerülhetett bele a SuperUser Tevékenység 
feliratú Application Policy elem. 


Kiadási feltételek 


Egy oldal maradt hátra a tanúsítványsablonok jellemzői közül: 
az Issuance Reguirements, azaz kiadási feltételek. 

A következő ábrán egy jócskán megszigorított kiadási feltéte- 
lekkel rendelkező tanúsítványsablont látunk. A CA certificate 
manager approval opcióról az előző részben már elmondtuk, 
hogy bekapcsolása esetén a sablonból készült tanúsítványt az 
Enterprise CA-k sem adják ki automatikusan, hanem minden 
esetben megvárják egy rendszergazda hozzájárulását 
(Certificate. Authority MMC konzol, Pending Reguests lista, 
Issue parancs). 

Emellett azonban létezik egy még komolyabb eljárás is: ha 
akarjuk, a tanúsítvány kiadását digitálisan speciálisan aláírt ta- 
núsítványkéréshez is köthetjük. Normális esetben egy tanúsít- 





ványkérést csak a tanúsítvány leendő boldog tulaj- 
donosa ír alá, de mi kikényszeríthetjük, hogy a tanú- 
sítványkérést elküldés előtt megadott típusú tanúsít- 
vánnyal (tanúsítványokkal) rendelkező ember(ek) is 
aláírják. 





Eyes dai ES 21xl 


Subject Name l 


Reguest Handling l 
Issuance Reguirements ] Superseded Templates ]. Extensions ] Security l 


General ] 


Reguire the following for enrollment: 
[7 CA certificate manager approval 
(7 This number of authorized signatures: [1 
If you reguire more than one signature, autoerrollment is not allowed. 


Policy type reguired in signature: 


Both application and issuance policy HV! 


Certificate Reguest Agent hé 


Issuance policies: 


High Assurance Add... 
Remove 


Reguire the following for reenrollment: 
(G Same ciiteria as for enrollment 
C Valid existing certificate 





A sablonból készült tanúsítvány kiadásának szigorú fel- 
tételei 


Ha a This number of authorized signatures: opciót bekapcsol- 
juk, a webes tanúsítványkérés már csak fájlba menteni lesz 
hajlandó minden kérést (jól is teszi, különben a kérést a Policy 
Modul a megfelelő aláírás híján azonnal vissza is utasítaná). 
Az opció utáni mezőben meghatározhatjuk, hogy a tanúsít- 
ványkérést elküldés előtt mennyi (természetesen egymástól 
különböző) digitális aláírással kell ellátni (az alapértelmezés 
az T, de ezt is szigoríthatjuk). A tanúsítványok automatikus 
kiadása (AutoEnrollment) csak akkor működik, ha ez az érték 
nem nagyobb egynél (ezt az egy digitális aláírást a Windows 
automatikus tanúsítványkérés esetén még képes elhelyezni a 
kérésen — persze csak akkor, ha a tulajdonos rendelkezik a fel- 
tételeknek megfelelő aláíró tanúsítvánnyal). 

A kérést aláíró tanúsítvánnyal szemben Application és/vagy 
Issuance Policy bővítmény-elvárásokat köthetünk ki. Az ábrán 
látható példa olyan aláíró tanúsítványt vár el, amit magas 
szintű biztonsági eljárás keretében adtak ki (azaz az Issuance 
Level mezőjében a High Assurance OID-je szerepel), vala- 
mint a Certificate Reguest Agent nevű Application Policy-vel 
rendelkezik. (Hozzátesszük, hogy az Issuance Policy elvárás- 
sal rendelkező tanúsítványkérések esetén kifejezetten ezt az 
Application Policy-t kell használnunk — a neve is ez: tanúsít- 
ványkérés-aláíró ügynök -—, különben magával a digitális 
aláírás végrehajtásával lesznek gondjaink). 

Természetesen azt is megtehetjük, hogy Issuance Policy köve- 
telményeket nem, csak Application Policy igényeket támasz- 
tunk — ekkor a Certificate Reguest Agent helyett választhatunk 
mást is. 
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A dialógusablak alján még azt kell meghatároznunk, 

! hogy a tanúsítvány megújítása esetén is leszünk-e 

pontosan ennyire szigorúak (azaz a megújító kérést 

is aláíratjuk-e) (Same criteria as for enrollment), vagy 

megelégszünk azzal, ha a tulaj rendelkezik a tanú- 

sítvány (még éppen) érvényes változatával (Valid existing 
certificate). 





A tanúsítványkérés digitális aláírása 

Amikor tehát egy tanúsítványsablon digitálisan aláírt, , jóváha- 
gyott" tanúsítványkérést definiál, a Windows webes felülete 
automatikusan fájlba menti a tanúsítványkérést. Ennek ered- 
ménye általában egy ".reg fájl. Miután a tanúsítványkérés el- 
készült, ezt a fájlt el kell juttatnunk az aláíró személyhez (va- 
lakihez, aki birtokolja az aláíráshoz szükséges paraméterekkel 
rendelkező tanúsítványt). Az aláírónak az alábbi parancsot 
kell kiadnia: 


certreg /sign ceredeti.reg; calairt.reg; 


Az ceredeti.reg; helyére értelemszerűen az eredeti kérésfájl, 
az calairt.reg: helyére pedig az aláírt eredményfájl nevét kell 
megadnunk. Ha az utóbbi paramétert nem adjuk meg, a meg- 
jelenő fájldialógusban menet közben is megtehetjük majd. Az 
aláíráshoz használt tanúsítványt a parancs futtatása során kell 
kiválasztanunk. 


CITES EKET al 


Ust Enrollment Registration Agent certificates 





Issued to 


Gatti 





4 I Ld) 


Cancel View Certificate 





fe:certreg /sign suüperuser.reg supersigned.reg 





E Tanúsítványkérés digitális aláírása 


A Certificate List ablakban az elvárásoknak megfelelő tanúsít- 
ványaink jelennek meg (ha a lista üres, nem rendelkezünk 
megfelelő tanúsítvánnyal). A tanúsítvány kiválasztása után az 


aláírt kérésfájl elkészül, amit immár elküldhetünk a Windows 
CA-nak, ha a webes felületen a fájlba mentett tanúsítványké- 
rés küldését választjuk, és a megfelelő mezőbe bemásoljuk a 
fájl tartalmát. Ne felejtsük el kiválasztani újra a használni kí- 
vánt tanúsítványsablont! 

Az digitálisan aláírt tanúsítványkérés elküldése (ha csak egy 
aláírásra van szükség, és rendelkezünk a kérés aláírásához 
szükséges tanúsítvánnyal is) a tanúsítványkezelő MMC kon- 
zolból egy kicsit egyszerűbb: 


KET LANE Sat 
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(JJ Console Root aj] Issued To Issued By 
7 ÉJ Certíicates - Current User [ [EJ administrator Administrator 
a Personal EHadministrator Falatrax CA 
Lz a te Te tEb] ")--, 
"a (I Trusted Root c ANETTE ANNK]! Regvest New Certificate... ) 
a. (I Enterprise Tru: BOE 
. 1 Intarmediata C Bew t ESETT SEg egy TETT KEN? 
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Az MMC konzolból egyszerűbb az aláírt tanúsítványké- 
rés elküldése 


A konzol Reguest New Certificate... parancsával indítható va- 
rázsló ugyanis automatikusan ellátja a kérést a megfelelő digi- 


tális aláírással. 


A következő részben a tanúsítványkiadók hierarchiájával kap- 
csolatos újdonságokról lesz szó. 


Folytatjuk... 


Fülöp Miklós 
mickEinetcom.hu 


ET LL 


http://technet.netacademia.net/go?kulcsszó címen érhetők el. 





ÍHT-T: IPoec NHI-on 


keresztü 


IPSec NAT Traversal — az IPSec új üzemmódja 


A Windows 2000-ben bevezetett IPSec protokoll egyik nagy hátránya volt, hogy az általa titkosított 
csatorna nem volt képes áthaladni hálózati címfordító (NAT — Network Address Translation) eszközö- 
kön. A Windows 2003 már tartalmazza, Windows 2000-hez és XP-hez pedig letölthető azt a bővítés, 


ami megoldja ezt a problémát is. 


A hálózati címfordításról címszavakban 


Mi is az a NAT? A Network Address Translation, azaz ,háló- 
zati címfordítás" egy olyan eljárást takar, amelynek során egy 
alhálózat kijáratánál található átjáró a rajta áthaladó hálózati 
csomagok fejlécét és tartalmát úgy módosítja, hogy elrejti a 
csomag eredeti ,származási" helyét, azaz a belső, védett há- 
lózaton található számítógépek IP-címét. A belső IP-cím he- 
lyére az átjáró külső , lábának" IP címe kerül, a válaszként ér- 
kező csomagok pedig ugyanide érkeznek. A külső hálózatról 
beérkező csomagok eljuttatása a megfelelő belső címzetthez 
a NAT átjáró feladata (többek között). 


Belső hálózat 







NP: 11.22.33.44 

Port: 5319 

PIZZA ZA3S 
Port: 80 






IP: 192.168.0.11 
Port: 3873 






kiszolgáló 


Ú 







B A hálózati címfordítás vázlata 


Nézzük például a fenti ábrát: itt a belső hálózaton található 
Ügyfél elindítja a webböngészőjét, és csatlakozni próbál a 
külső hálózaton található webkiszolgálóhoz. Az Ügyfél belső 
IP címe egy privát cím, 192.168.0.11. A kapcsolathoz a bön- 
gésző az ügyfél operációs rendszerétől a 3873-as TCP port cí- 
met kapja. Az ügyfél számítógépét elhagyó csomag feladója 
tehát a következő ,feladó" adatokat tartalmazza: 
192.168.0.11:3873. A csomag eljut az alapértelmezett átjáró- 
hoz, ami NAT feladatokat is ellát. A NAT pedig, mielőtt a cso- 
magot továbbítaná, a benne található belső IP-címet a saját 
külső, nyilvános IP címére cseréli (11.22.33.44). Miután az 
ügyfél által használt portcím (3873) az átjáróban egyáltalán 
nem biztos, hogy szabad, a router általában egy másik 
portcímet kér az operációs rendszertől (példánkban az 5319- 
et kapja). A nyilvános hálózatra kilépő csomag feladója tehát: 
11.22.33.44:5319. 

Ezt az összerendelést az átjáró egy belső táblázatban szépen 
meg is jegyzi, hiszen a beérkező csomagok továbbításához er- 
re szükség is lesz: 


Külső IP-cím Külső Port 
.  T1.22.33.44 — 5319 


. Belső IP-cím — Belső Port 
192.168.0.11 3873 


S Példa egy NAT táblázatból 


A csomag eljut a webkiszolgálóhoz (22.33.44.55:80), aki a 
választ . természetesen a feladónak küldi vissza: 
11.22.33.44:5319. Az átjáró a beérkező csomag cél-IP és 
portcímét megkeresi a NAT-táblázatban, majd a megfelelő 
módosítások (fejlécmódosítás) után továbbítja a csomagot az 
eredeti feladónak (192.168.0.11:3873). 

A NAT táblázatbeli összerendelés TCP csatorna esetén egé- 
szen addig érvényes, amíg az ügyfelek le nem bontják a TCP 
csatornát. UDP kommunikáció esetén azonban nincs csator- 
naépítés, csak ad hoc közlekedő csomagok. Összerendelő 
táblázatbejegyzés természetesen UDP csomagok esetén is ké- 
szül a NAT-ban, de ezek a bejegyzések, adott idő (Time-Out) 
múlva automatikusan megszűnnek. 

Ez azonban csak a jéghegy csúcsa: a NAT eszköz a fejlécek 
csereberélésén és a csomagok továbbításán kívül még sok 
minden mást is művel. Vannak többek között olyan protokol- 
lok, amelyek nemcsak a csomagok fejlécében, de magukban 
az átvitt adatokban (a kommunikációban) is továbbítják az IP- 
cím információkat (ilyen például az FTP is). Ha a NAT csak az 
FTP csomagok fejlécét cserélgetné, a csomagokon belül talál- 
ható címek a belső címek maradnának, és az FTP nem mű- 
ködhetne. Ezért a NAT felismeri és módosítja az ilyen kényes 
protokollok tartalmát is (ez már egyébként az Application 
Layer Gateway, ALG feladata). Ennyi (rövid és felületes) beve- 
zető után már itt az ideje rátérnünk az IPSec és a NAT problé- 
májára. 


Mi a baj az IPSec-kel? 


Az előző bekezdés elolvasása után már nagyjából lehet sejte- 
ni, mi a probléma az IPSec csomagokkal. A probléma sokrétű 
(akit részletesen érdekel, az lipsecnatreg] címről letölthető 
dokumentumban elolvashatja). Néhány példa: 


1. Az ISAKMP/Oakley protokoll 

Az IPSec csatorna kiépítését az ISAKMP/Oakley protokoll se- 
gítségével végzik a kommunikációban majdan résztvevő szá- 
mitógépek. Az ISAKMP protokoll tartalmazza a csatorna két 
végpontjának IP-címét (ami NAT esetén természetesen meg- 
változik). 


2. Az ESP protokoll 

A titkosított csatorna kiépítése után a titkosított IPSec kommuni- 
káció ESP csomagok formájában halad a hálózaton. Ezek a cso- 
magok csak az IP-címeket, illetve egy belső azonosítót (SP/) tar- 
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IPSec NAT-on keresztül 
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talmaznak. Amikor a csomag eljut a címzetthez, az az 
SPI alapján dönti el, hogy a csomag melyik alkalma- 
záshoz tartozik (az SPI nagyjából a TCP/UDP portcím 
szerepét tölti be). Emellett az SPI utal természetesen 
magára az IPSec ,csatornára" is. Egy számítógép 
ugyanis egynél több IPSec csatornát is kiépíthet, ugyanazzal a 
számítógéppel, vagy más partnerekkel, és minden IPSec csator- 
na beállításai (azonosítási mód, titkosítás, a kulcsmenedzsment 
értékei) csatornánként különbözőek is lehetnek. 

Pillantsunk vissza a NAT vázlatára! Ha a belső hálózatból 
egyidejűleg több ügyfél próbálna IPSec-kapcsolatot építeni a 
kiszolgálóval (még ha az ISAKMP miatt sikerülne is), a NAT 
nem lenne képes feldolgozni a beérkező ESP csomagokat 
(nem tudná, melyik belső ügyfélnek továbbítsa azokat). Az 
SPI-érték a NAT számára nem mond sokat, ugyanis az a kü- 
lönböző , irányba" haladó csomagok esetén különböző. 


3. Az AH protokoll 

Ha az IPSec kommunikáció nem titkosított, csak a csomagok 
integritásvédelmét (digitális aláírását) vesszük igénybe, az 
IPSec hálózati forgalom ESP helyett AH (Authenticated 
Header) csomagok formájában halad a hálózaton. Az AH cso- 
mag digitális aláírása azonban tartalmazza a feladó és címzett 
IP-címét, a csomag fejlécének megváltoztatása tehát elrontja a 
csomagok digitális aláírását, és érvényteleníti azokat. 


A megoldás 


A megoldás kétrétű: egyrészt, az ISAKMP protokollt kell felké- 
szíteni a NAT kezelésére (az ISAKMP protokoll az UDP 500- 
as portot használja), másrészt pedig az ESP csomagok továb- 
bítását és pontos célbajuttatását kell megoldanunk. (A specifi- 
káció jelenleg az AH csomagok átvitelét nem támogatja.) Az 
első feladat viszonylag egyszerű, az UDP protokoll ugyanis 
önmagában elviseli a NAT-ot (kivéve azt az apróságot, hogy 
az UDP-összerendelések a NAT-táblából egy idő után szeret- 
nek törlődni). Az ISAKMP esetében tehát gyakorlatilag csak a 
protokoll bővítésével kell foglalkozni. 

Az ESP csomagok védelme kicsit összetettebb, de a megoldás 
gordiuszi: ha az ESP nem viseli el a NAT-ot, az UDP viszont 
igen, miért ne csomagolhatnánk be az ESP csomagokat UDP- 
ruhába a továbbítás idejére? Ez lesz az UDP 4500-as port, 
amibe — mint majd látni fogjuk — az ISAKMP protokoll jó ré- 
sze is beköltözik majd. 

A megoldáscsomagot NAT-Traversalnak (NAT-T, NAT-átjárás) 
nevezték el. 





Az ISAKMP bővítményei 


Az ISAKMP protokoll az UDP 500-as portcímet használja, 
ráadásul az eredeti IPSec-implementációban úgy, hogy a cso- 
magok feladó és portcíme egyaránt az UDP 500 volt. Ha be- 
legondolunk egy kicsit, ez már önmagában gondot okoz a 
NAT-nál, ugyanis a NAT mögül kiküldött ISAKMP csomag 
portcíme legkésőbb a második számítógép próbálkozásakor 
már foglalt lesz. 

Az első lépés tehát az volt, hogy mostantól a hálózati eszkö- 
zöknek és számítógépeknek akkor is fogadni és kezelni kell az 
ISAKMP csomagokat, ha azoknak a feladó port címe nem, 
csak a címzett port címe 500. Ha például az ISAKMP csomag 
a feladó UDP 12345-ös portcíméről a címzett UDP 500-as 
portjára érkezik, azt fel kell dolgozni, a válaszokat pedig (ér- 
telemszerűen) a feladó UDP 12345-ös portjára kell küldeni. 
A következő lépés annak kiderítése, hogy az IPSec-csatornát 


építő felek közül ki ismeri a NAT-T üzemmódot. Ezt a tagok 
nagyon egyszerűen, az első ISAKMP csomagba kölcsönösen 
elhelyezett, előre definiált Vendor-ID bájtsorozat elhelyezésé- 
vel illetve kiolvasásával döntik el. 


A NAT felismerése: NAT-D 


A NAT-T kompatíbilis ISAKMP protokoll képes felismerni, ha az 
adatátviteli csatorna címfordításon halad keresztül. Az ISAKMP 
harmadik (válaszként pedig negyedik) csomagjában mindkét 
fél elküldi a saját illetve másik tag (általa ismert) IP-címéből és 
portcíméből készült hash-értéket. (Ha a gépnek több saját IP- 
címe van, mindegyikhez készül egy-egy NAT-D hash). Ha a 
Windows 2003 Network Monitorával megnézünk egy ilyen 
forgalmat, láthatjuk is az ISAKMP NAT-Discovery részét: 


§) FRAME: Base írame properties 

§ ETHERNET: EType - Internet IP (IPv4) 

4 IP: Protocol : UDP - User Datagram; Packet ID z- 53602; 

4 UDP: Src Port: isakmump (500); Dst Port: isakup (500); L- 

7 ISAKMP: Major Version: 1 Minor Version: 0 Length: 23: 
ISAKMP: Initiator cookie z 7B 74 B9 96 4l F6 CF 08 
ISAKMP: Responder cookie s 19 EA BB 45 OA 9E AF 20 
ISAKHP: Next payload - Key Exchange 


ISAKMP: Major version z 1 (0xl) 

ISAKMP: Minor version z 0 (Ox0) 

ISAKMP: Exchange type - Identity Protection 
§) ISAKMP: Flags summary z 0 (0x0) 


ISAKMP: Message ID - 0 (0x0) 
ISAKMP: Length - 232 (0xE8) 
§ ISARMP: Payload type - Key Exchange 
8] ISAKMP: Payload type z N. 
SE EZEt] 
ISAKMP: Next payload z NAT Discovery 
ISAKMP: Reserved z 0 (0x0) 
ISAKMP: Payload length - 24 (0x18) 
ISAKMP: NAT Discovery data z DO C9 E7 53 36 FC E7 
§ ISAKMP: Payload type s NAT Discovery 











E NAT-D hash az ISAKMP csomagban 


Miután a csomag megérkezik, a címzett elvégzi ugyanezeket 
a hashműveleteket az általa ismert címekkel. Ha a két hash 
nem egyezik, az IP-cím vagy a portcím a csomag továbbítása 
közben megváltozott, tehát a kommunikáció során valahol 
címfordítás történt (sőt, még az is kiderül, hogy melyik félnél). 


A NAT-T kommunikációs port (ISAKMP2, UDP 4500) 


Miután kiderült, hogy a NAT-T-re szükség van, a korábban 
említett okok miatt a rendszer áttér az UDP 4500-as port hasz- 
nálatára (ettől a pillanattól kezdve a teljes kommunikáció s0- 
rán az ISAKMP már itt utazik, az UDP 500-as port helyett). Ezt 
egy (Windows 2003 Server-beli) Network Monitor segítségé- 
vel szépen lehet is követni. 

Az ISAKMP2 csomagok a feladó UDP 4500-as portjáról a cél- 
gép UDP 4500-as portjára indulnak el, de a feladó végleges 
portcíme (és persze IP címe) a NAT miatt ettől végül eltérő lesz: 


Kiszolgáló 


UDP 0000 £- UDP 4500 


Belső hálózat 


F UDP 4500 - UDP 4500 UDpega -32 UDP 4500 








UDP 4500 c- 


E Az I ISAKMP2 által használt portcímek 


A kiszolgáló válasza értelemszerűen a NAT által módosított 
portcímre érkezik, ami aztán a NAT-táblázat alapján jut el a 
belső ügyfélhez. 


A NAT Keep-Alive csomag 


A felépített csatorna védelme érdekében a NAT-T üzemmód- 
ban futó ISAKMP adott időnként (20 másodpercenként) úgy- 
nevezett NAT Keep-Alive csomagot küld. Ez egy olyan 
ISAKMP2 UDP-be ágyazott , félkész" ESP-csomag, amely 
egyetlen bájtot tartalmaz (értéke $FF). Ezt a csomagot az IPSec 
figyelmen kívül hagyja, a NAT átjáró viszont ennek köszönhe- 
tően életben tartja az amúgy illékony UDP-összerendelési be- 
jegyzést a NAT-táblában. 


Az UDP-be ágyazott ESP forgalom 

Végül elérkeztünk a lényeghez: a sok körítés mellett-után meg- 

kezdődhet a titkosított IPSec kommunikáció! Az ESP csomagok 

SAKMP2 csomagba ágyazva utaznak a hálózaton. Lássunk egy 
etwork Monitor részletet egy NAT-T nélküli ESP csomagról: 
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Trana Time Se HAC Adár [Dzc MaC Adar Prorocol ] Dezeription 

16 9.BG3A4E  KATRONACECEK INTERPSESDOK ISAMIP — Hajor Version; : Minor Version 
19 9.891464 — INTERPOSSDOA KATRONACECEE OzPCSICACT, 509 " Oxi 

TO 10.760089 INTERPOSSDOA KATPONWCECEK ORFCSICACF, 5eg " OzZ 


10.7600$9  KATRONACECBE INTERPISSDOA 
10.7600£9  KATPON4CECEE INTEPP?SSDOA 
10.760059  KATRONACECEE INTERPSSSDOA 


Oz43B44495 
2 Ox4JB4449 
0542844497, 


2 Oxi 
2 0zZ 
2 0zT 











TT TPANE: Base frame propertiet 
§ ETHEPRHET: ETI 









Protocol: Packot ID e $I71Z4 


AZI6264455 (OZFCSICACTI 





ESP: Soguence Munber s 1 (051) 


E Az eredeti megoldás: IPSec NAT-T nélkül 


Figyeljük meg, hogy az ESP réteg közvetlenül az IP protokoll 
után következik. Vessük össze most ezt egy NAT-T üzemmód- 
ban zajló forgalommal: 
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AjEe Edt Display Tools Options Window  tielp 
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UDP 500 feladó és címzett portcímmel zajlott) szűrő. 
je engedélyezi-e az UDP 500-tól eltérő portcímről 
beérkező csomagokat is. Az ESP csomagok átvitelé- 

nek támogatására viszont már nem lesz szükség. 

Az ISA Server például egy parancs segítségével auto- 
matikusan képes létrehozni az eredeti (L2TP over) IPSec imp- 
lementációhoz szükséges csomagszűrőket. Ezek közül az 
,Allow L2TP Protocol IKE Packets" csomagszűrő beállításait 
kell módosítanunk, attól függően, hogy a tűzfal mögötti ki- 
szolgáló fogadja vagy kezdeményezi a kapcsolat felépítését. 
Ha mindkettőt, akkor újabb csomagszűrő szabályt is kell lét- 
rehoznunk. 





Allow LZTP protocol IKE packets Properties 2] 


General Filter Type ILocat Computer ] Remote Computer ] 







Use this filter: 


C Predefined: 





IP protocok UDP se 


T—— 


Protocol number: 


Direction: [Bon 7] 
Local port: [Feedpn 7] 


Local port number: 


[Foo 


] 

! 
[Fixed port BE 
Remote port numbet 500 


Remote port 








Fraue [Tin Srec MAC Adar [Dor MAC Addr [ Protocol [Description 


10 7.099206 — LOCAL DOSOSGPPEZOC ISAKMP Major Version: 1 Minor Vere 











11 7.1E92S4 — OOSOSEFFEZOC LOCAL ISAKMP Major Version: 1 Minor Vers 
17 7.176259 — LOCAL OOSOSGFFEZOC ISAKHP — Hajor Version: 1 Minor Vers: 
42 7.218288 — OOSOSÉFPEZOC LOCAL ISAKNP Major Version: 1 Minor Vere 
14 7.281331 — LOCAL DOSOSSPFEZOC  ESP SPI " Ox335FOlA4, Seg " 

15 7.S1Z489 — OOSOSEPFEZOC LOCAL asp SPI 5 OR1FB9CS1O, Seg 5 Oxi 





4 ] 





"FRAME: Base trame properties 

§ ETHERNET: EType e Internet IP (IPv4) 

9 IP: Protocol : UDP - User Datagram; Packet ID 7 

9 UDP: Sre Port: ísakmpZ (4500); Det Port: irakapi 
ISAKMP: UDPESP 





2606; Total IP Length s 192: Opti 
(450095 Length s 172 (OZAC) 








curity Parameters Index s SEL864256 (ORJJSFOLA4) 
ESP: Seguence Number s 1 (Ox1) 








E Az ESP új ruhája: NAT-T üzemmódban UDP-be csoma- 
golva 


Ha jól megnézzük az ábrát, észrevethetjük, hogy az IP és az 
ESP közé egy UDP réteg ékelődött be (talán nem meglepetés, 
hogy az UDP 4500-as portcímen). Ennek a csomagolásnak 
(no és persze az előző két oldalon leírtaknak) köszönhetően 
az ESP vígan közlekedik keresztül a címfordításon is. 

(Ha a fenti csomagokat nem Windows 2003-beli Network 
Monitorral nézzük, a NetMon az első négy (UDP 500-as 
porton haladó) ISAKMP csomag kivételével csupa ismeretlen 
UDP forgalmat jelenítene meg.) 


Tűzfalkonfiguráció 


Az új kommunikációs port bevezetése azt jelenti, hogy a NAT- 
T IPSec támogatásához módosítanunk kell az esetleg jelen lévő 
tűzfalaink beállításait. Az előző oldalon leírtuk az ISAKMP 
portcímeinek alakulását (feladó: UDP xxxxx, címzett: UDP 
4500). Ehhez új csomagszűrőt kell engedélyeznünk. Emellett 
ellenőrizzük, hogy az eredeti ISAKMP forgalom (ami UDP 500- 





a Az ISA Server automatikusan létrehozott csomagszűrő- 
jét módosítanunk kell 


Emellett természetesen létre kell hoznunk azokat az új cso- 
magszűrőket is, amelyek az új ISAKMP2 protokollt engedik át. 
Összefoglalva tehát: 





(elt Eg lé ee ET ő 


ela een 


Bejövő ISAKMP UDP 500 UDP összes 
Bejövő ISAKMP2 UDP 4500 UDP összes 
Kimenő ISAKMP UDP összes UDP 500 
Kimenő ISAKMP2 UDP összes UDP 4500 


Támogatás 

Az IPSec NAT-Traversal a Windows Server 2003-ban már 
megtalálható. Windows 2000-hez és Windows XP-hez a 
[w2kxpl címről, a 818043-as Tudásbázis-cikkből tölthető le. A 
cikk írásának pillanatában a Windows XP-re írt frissítés átme- 
netileg nem érhető el, de reménykedjünk, hogy ami késik, az 
nem múlik. Megéri várni! 


Fülöp Miklós 
mickGinetcom.hu 
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mm 


Biztonságos aláíráskezelű al- 
kalmazás [BALE] készítése ID. 


Adatok és komponensek 


A hosszúra nyúlt bevezetés után végre eljutottunk a gyakorló informatikus kollégák számára minden 
bizonnyal kedvesebb témákhoz. Jelen részben az aláíráskezelő alkalmazás által használt adatokról, az 
aláíráslétrehozó alkalmazás ezeket hasznosító komponenseiről, valamint az alkalmazással szemben 
támasztott követelményekről lesz szó. Egyben folytatódik a mindennek nevet adunk-szakkör, ami most 
ér igazi csúcspontjára, hiszen most egyes fogalmaknak új elnevezést adunk. Tessék kapaszkodni, mert 
aki eddig netán értette, az most könnyen elveszítheti a fonalat. 


Mielőtt belekezdenék azért megjegyzem, hogy ezt az átke- 
resztelési játékot nem személyes antiszociális indíttatásból te- 
szem, hanem mert ez az ,iparági gyakorlat". Az egyes külön 
dolgozó szabványügyi szervezetek, csoportok, cégek mind sa- 
ját fogalmakat alkotnak ugyanazon dolgokra, néha házon be- 
lül is többet, attól függően, hogy a téma mely részére koncent- 
rálnak épp. Jobbnak láttam, ha nem egységesítem ezeket az 
elnevezéséket, inkább használom az eredetieket, jelölve, 
hogy máshol, máskor miként nevezik ugyanazt. Így felvérte- 
ződve már nem érheti nagy meglepetés azokat, akik más for- 
rásból is tájékozódnak. 


Az aláíráskezelő alkalmazás adatai 


Az aláíráskezelő alkalmazás egyes komponensei a követ- 
kező adatokat és információs egységeket kezelik: 

A Aláírói dokumentum: az a bármilyen tartalmú doku- 
mentum, melyet az aláíró el kíván látni az aláírásával. 

mA Aláírásjellemzők: az aláírás olyan kiegészítő adatai, 
amelyek az aláírási szabályzatnak megfelelően az 
aláírói dokumentummal együtt aláírásra kerülnek (lásd 
tételesen később). 

HA Aláírandó adat alkotóelem: az aláírásjellemzők és az 
aláírói dokumentum önállóan. 

mA Aláírandó adat: az aláírói dokumentum, az aláírás- 
jellemzők és opcionálisan egyéb aláírásra kerülő infor- 
mációk (ld. később) együtt. 

H Formattált aláírandó adat: az aláírandó adat az aláírási 
szabályzat és/vagy az alkalmazás előírásai szerint for- 
mattálva, az aláírandó adat formattáló által (pl. XML 
Advanced Electronic Signature formátumra). 

HA Aláírandó adat képviselő: a formattált aláírandó adat 
lenyomata, melyet a lenyomatoló komponens állít elő, 
majd formattált (feltöltött és szabványos formára ho- 
Zott). Ezt az adatot küldi az alkalmazás a BALE-nak 
aláírásra. 





A Aktiválási adat: a BALE aktiválására, illetve az aláíró 
BALE felé történő hitelesítése szolgáló adat. 

HA Minősített elektronikus aláírás: Az aláíró algoritmussal 
a BALE által kódolt aláírandó adat képviselő (korábban 
digitális aláírásnak volt nevezve). 

TA Aláírt adathalmaz: a minősített elektronikus aláírás és a 
formattált aláírandó adat mezői, egyéb aláírással nem 


ellátott információkkal együtt, melyeket az aláírt adat- 
halmaz összeállító állított össze az aláírt adathalmaz tí- 
pusnak megfelelően. Ide kerülhet az aláírás értékén 
végzett időbélyegző, mely az aláírás idejét hivatott iga- 
zolni. Ez az aláíráslétrehozó alkalmazás kimenete, amit 
korábban elektronikus aláírásnak hívtunk. 

A Aláírt adathalmaz-típus: az aláírt adathalmaz típusa, 
amely meghatározza az aláírt adathalmaz tartalmát és 
formátumát. 

A BALE-tulajdonos azonosító: a BALE-tulajdonosának 
azonosító adata (jellemzően neve), mely a BALE felüle- 
tén (pl. kártyán dombornyomottan) vagy a belsejében 
elektronikusan van feltüntetve/tárolva. 

HA BALE-információ: BALE-tulajdonos azonosító és egyéb 
BALE adatok. 


Az aláírás megtétele során felhasználásra kerül az ún. 
aláíráslétrehozó adat is, mely (immár újabb definícióval) a 
BALE által az aláírandó adat képviselő kódolására felhasznált 
adat. Ezt az adatot az alkalmazás (közvetlenül) nem kezeli. 


Az aláírásjellemzők a következők lehetnek: 

A Aláíró tanúsítványa: az aláírás megtétele során az 
aláírásban résztvevő aláíráslétrehozó adat kiválasztásá- 
ra szolgál (különösen amennyiben aláíró több 
aláíráslétrehozó adattal rendelkezik). Az aláírás el- 
lenőrzésekor az aláírás értékének dekódolására, vala- 
mint a nyilvános kulcs aláíróhoz tartozásának és érvé- 
nyességének megállapítására használatos. 

A Aláírási szabályzat referencia: utalás az aláírási sza- 
bályzatra, mely alapján az aláírás készült, s mely alap- 
ján az ellenőrizhető és értelmezhető. 

AA Kötelezettségvállalás típusa: az aláíró 








által az aláírással 


kifejezni kívánt szándék az aláírási szabályzatnak meg- 
felelően (amennyiben az aláírási szabályzat több ilyet 
megkülönbözte0). 

JA Tartalomformátum: az aláírói dokumentum formátuma, 





mely az aláíró és ellenőrző általi megtekintést és hasz- 
nálatot meghatározza. 

A További aláírásjellemző lehet bármi, amit az aláírási 
szabályzat vagy más előírás meghatároz, pl. időbélyeg- 
ző, archív tanúsítványok. 


Egyéb aláírásra kerülő információk a következők lehetnek: 

H Az aláírás ideje az aláíró állítása szerint. 

HA Az aláíró kinyilvánított szerepköre. 

A Az aláíró hitelesített szerepköre (pl. attribútum tanúsít- 
vány). 

A Az aláírás fizikai helye az aláíró állítása szerint. 

HA Időbélyegző az aláírói dokumentumról vagy más adat- 
ról (ami nem az aláírás idejét tanúsítja, bár arra bizo- 
nyíték, hogy az aláírás csak az időbélyegzőben szerep- 
lő időpont után jöhetett létre). 

H Bármilyen további adat, amit az aláírási szabályzat 
meghatároz. 


Az aláíráslétrehozó alkalmazás komponensei 

A bemutatott adatokat az aláíráslétrehozó alkalmazás követ- 
kező komponensei kezelik. A komponensek két kategóriába, 
a megbízható összetevők és az alkalmazásspecifikus összete- 
vők csoportjába oszthatók. A megbízható összetevőknek min- 
den aláíráslétrehozó alkalmazásban megtalálhatónak kell len- 
ni. Az alkalmazásspecifikus összetevők jelenléte feltételes, 
felépítésük és működésük az alkalmazási környezettől és kö- 
rülményektől függ. 


Az aláíráslétrehozó alkalmazás megbízható összetevői a 
következők: 

Aláírói dokumentum megjelenítő 

Aláírásjellemzők megtekintő 

Aláíró interfész komponens 

Aláíró hitelesítő komponens 

Aláírandó adat formattáló 

Lenyomatoló komponens 

BALE-kommunikátor 


Az alkalmazásspecifikus összetevők az alábbiak: 
Aláírói dokumentum összeállító 
Aláírt adathalmaz összeállító 
Aláírásnaplózó komponens 
Szolgáltatói együttműködő komponens 
BALE-tulajdonos kijelző 


Aki tervezett vagy fejlesztett már aláíráskezelő alkalmazást, az 
bizonyára találkozott az említett adatok és komponensek né- 
melyikével. Csak nem nevezte és különítette el őket így. Ter- 
vezés és (tanúsítást megelőző) dokumentálás előtt minden- 
képp érdemes hasonló módon komponensekre bontani az al- 
kalmazást és a kezelt adatokat. Azokat a műveletek, amelyek 
az egyes komponensek funkcionalitását kielégítik, szinte biz- 
tosan ott lesznek az alkalmazásban, így nem jelent járulékos 
fejlesztési feladatot ekomponensek megvalósítása. Jobb eset- 
ben csak egy új szemléletmódot kell magunkévá tennünk, 
mely biztosan kifizetődő. 

Az egyes funkciók logikai és fizikai elkülönítése, ha nem is 
növeli közvetlenül az alkalmazás biztonságát, jobban átte- 
kinthető, könnyebben tesztelhető rendszert eredményez, 
melynek tanúsításával is kevesebb gondunk lesz. 










Aláíráslétrehozó alkalmazás 
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5 Aláíráslétrehozó alkalmazás komponensei 


A működés áttekintése 


A következő ábrán az aláírás létrehozásának menetét szemlél- 
tetem, az egyes komponensek szerepének, az egyes adatok, 
egyéb külső szereplők, a BALE és az aláíró közreműködésé- 
nek feltüntetésével (a komponensek téglalapban, az 
alkalmazásspecifikus komponensek szaggatott vonallal, a ke- 
zelt adatok rombuszban, az egyéb külső szereplők hatszög- 
ben, a BALE és az aláíró közreműködése ellipszisben, a lépé- 
sek sorszámozásával van jelölve). 


Aláírói dokumentum megjelenítő 


Az aláírói dokumentum megjelenítő feladata, hogy az aláírói 
dokumentum összeállító által előállított aláírói dokumentu- 
mot a tartalomformátumnak megfelelő módon megjelenítse 
az aláíró számára. Ennek célja, hogy az aláíró megbizonyo- 
sodhasson arról, hogy valóban azt írja alá, amit szándékozik 
(amit az aláíró interfész komponenssel kiválasztott). Az 
összeállító és megjelenítő funkciók szétválásának az oka, 
hogy az összeállító általában nem képes a megjelenítő bizton- 
sági kritériumainak teljesítésére. Az aláírói dokumentum meg- 
jelenítő viszont minden bizonnyal csak véges számú tartalom- 
formátumot kezel. 

Az aláírói dokumentum összeállító és megjelenítő elvileg 
megegyezhet: vagy azon a módon, hogy az aláírói dokumen- 
tum összeállító egyben aláíráslétrehozó alkalmazás is (amihez 
az aláíráslétrehozó alkalmazás összes biztonsági kritériumát 
ki kell elégítenie), vagy úgy, hogy az aláíráslétrehozó alkalma- 
zás az aláírói dokumentum összeállítót használja aláírói do- 
kumentum megjelenítőként (mely esetben csak a megjelenítő 
biztonsági kritériumait kell kielégítenie). 


Aláírásjellemzők megtekintő 


Az aláírásjellemzők megtekintő feladata, hogy az aláíró szá- 
mára megjelenítse az általa (az aláíró interfész komponenssel) 
kiválasztott és/vagy az aláíráslétrehozó alkalmazás által az 
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w aláírandó adathoz rendelt összes aláírásjellemzőt, 
! abból a célból, hogy aláíró számára egyértelművé 
] tegye az aláírói dokumentum értelmezését és az 
aláírás által kifejezett szándékot. Ez a komponens je- 
leníti meg például a kiválasztott kötelezettségválla- 

lás típusát és az aláíró tanúsítványát. 


Aláíró interfész komponens 


Az aláíró interfész komponens feladata, hogy illesztőfelületet 
képezzen az aláíró és az "aláíráslétrehozó alkalmazás között, 
abból a célból, hogy az aláíró számára irányíthatóvá és 
ellenőrizhetővé tegye az aláírás előállítási eljárást (pl. aláírás 
jóváhagyása), valamint, hogy az ke 
aláíráslétrehozó alkalmazás szá- 
mára lehetővé tegye az aláíró felé 
történő jelzéseket (hibajelzés, fi- 
gyelmeztetés, kérdések stb.). 

Az aláíró interfész komponens ille- 
tékességi körébe tartozik minden 
alkalmazás-aláíró kommunikáció, 
kivéve az aláíró BALE felé történő 
hitelesítését. 





Aláíró-hitelesítő komponens 


Az aláíró-hitelesítő komponens 
feladata, hogy az aláíró BALE felé 
történő hitelesítéséről gondoskod- 
jon. Ennek egyik módja, hogy az 
aláírótól elkért BALE aktiválási 
adatot összehasonlítja a BALE-n tá- 
rolttal. Megvalósulhat a PIN kód 
billentyűzeten keresztüli bevitelé- 
vel, biometrikus azonosítással és 
egyéb módszerekkel is. Az alkal- 
mazott módszertől függően szük- 
ség szerint igénybe veszi a BALE- 
kommunikátort. 


Aláírandó adat formattáló 


Az aláírandó adat formattáló 
feladata, hogy az aláírói dokumen- 
tumból és az aláírásjellemzőkből 
előállítsa a formattált aláírandó 
adatot, a kiválasztott aláírási sza- 
bályzatnak és/vagy az aláíráslétre- 
hozó alkalmazás képességeinek 
megfelelően. 


Lenyomatoló komponens 


A lenyomatoló komponens felada- 

ta az aláírandó adat képviselő 

előállítása a formattált aláírandó adatból, és ennek formattálá- 
sa. Ez a gyakorlatban a lenyomat generálását, szükség szerint 
feltöltését (padding) és előírások szerinti formattálását jelenti 
(pl. PKCS §1, IS50-IEC 9796-2 formátumba). A lenyomat gene- 
rálásában és feltöltésében képességei szerint részt vehet az 
aláíráslétrehozó eszköz is. 


BALE-kommunikátor 


A BALE-kommunikátor feladata, hogy az aláíráslétrehozó al- 
kalmazás és a BALE közti adatcserét kezelje, ennek biztonsá- 
gáról gondoskodjon. 





Aláírói dokumentum összeállító 


Az aláírói dokumentum összeállító általában egy szövegszer- 
kesztő (pl. Word), de lehet más dokumentumkészítő program 
is (táblázatkezelő, prezentációkészítő stb.), sőt az aláírási sza- 
bályzatban meghatározott tartalomformátumokat előállít 
bármilyen alkalmazás is. Feladata, hogy előállítsa az aláírói 
dokumentumot. 





Aláírt adathalmaz összeállító 


A komponens feladata, hogy az aláírt adathalmazt összeállít- 
sa az aláíró által kiválasztott aláírt adathalmaz típusnak meg- 
felelően. 








E Aláírás létrehozása 


Inputja a minősített elektronikus aláírás és opcionálisan a for- 
mattált aláírandó adat, illetve annak mezői. Ezen kívül egyéb, 
aláírással el nem látott információkat is tartalmazhat. Az alkal- 
mazásnak érdemes rejtjelezési képességgel is rendelkeznie az 
aláírt adathalmaz bizalmasságának biztosítására. 


Aláírásnaplózó komponens 
Az Aláírásnaplózó komponens az aláíráslétrehozó eszközön 


naplózza az egyes aláírások legfontosabb adatait (aláírás, le- 
nyomat, időpont, aláírói dokumentum azonosító, alá- 





írásjellemzők, stb.). Ennek célja, hogy az aláíró a napló ada- 
taiból észrevegye az eszköz használatával kapcsolatos esetle- 
ges visszaéléseket (hogy valaki más használta aláírásra), vala- 
mint képes legyen saját aláírásainak későbbi azonosítására. 
Az aláíráslétrehozó eszközök erősen limitált memóriája ter- 
mészetesen csak véges számú naplóbejegyzés támogatására 
képes, ami a gyakorlatban ciklikus naplózást jelent, a legré- 
gibb naplóbejegyzések mindenkori felülírásával. 

Az aláíráslétrehozó alkalmazás szerepe, hogy az aláíráslétre- 
hozó eszköz naplózási funkcióját ellássa az ehhez szükséges 
adatokkal (pl. aláírói dokumentumazonosító, aláírásjellem- 
zők), illetve az eszközön elvégezze a naplózást, amennyiben 
az eszköz ilyen beépített funkcióval nem rendelkezik. 
Amennyiben az eszköz így sem teszi lehetővé a naplózást, 
ajánlott legalább az elvégzett aláírások számának naplózása 
slétrehozó adatonkért, illetve tanúsítványonként. 

Az aláíráslétrehozó alkalmazásnak biztosítania kell a napló- 
zott adatok megtekintésének lehetőségét is az aláíró interfész 
komponensen keresztül. 





Szolgáltatói együttműködő komponens 


A komponens az elektronikus aláírási szolgáltatókkal (hitelesí- 
tésszolgáltató, időbélyegző szolgáltató) való együttműködés- 
ről gondoskodik. Feladata többek között tanúsítványok impor- 
tálása (szolgáltatótól), érvényességük ellenőrzése, időbélyeg- 
ző kérése. A tanúsítványok letöltése és érvényességének el- 
lenőrzése az aláírói dokumentumban szereplő egyéb aláírá- 
sokkal kapcsolatban (többszörös aláírások), illetve aláíró saját 
tanúsítványával kapcsolatban lehet szükséges (amennyiben a 
BALE azt nem tárolja). 


BALE-tulajdonos kijelző 


A BALE-tulajdonos kijelző komponensnek a BALE-n elektroni- 
kusan tárolt tulajdonos azonosító kijelzéséről kell gondoskod- 
ni, az aláíró interfészkomponensen keresztül. Ez olyan esetek- 
ben különösen fontos, mikor az eszközön nem lehetséges a 
név hagyományos írott formában történő feltüntetése (pl. USB 
token, HSM). 


Általános követelmények 


Az aláíráslétrehozó alkalmazás tervezésekor és fejlesztésekor 
számos biztonsági és funkcionális követelményt kell a szak- 
embereknek figyelembe venni. Az összes követelmény megis- 
mertetéséről terjedelmi okok miatt le kell mondanom, de a 
fontosabbakat és érdekesebbeket bemutatom, a követelményt 
indokoló veszélyekkel, és néhol a lehetséges megoldásokkal 
együtt. A biztonsági követelmények között vannak általáno- 
sak, melyek az alkalmazás egészére vagy összes moduljára 
vonatkoznak, valamint az egyes adatokra és komponensekre 
specifikusak. 


Az általános biztonsági követelmények közé sorolhatóak 
a következők: 

H Garantálni kell az alkalmazásnak, a komponensek, 
konfigurációs adatok és paraméterek sértetlenségét, 
illetve az ezekben történő (vétlen vagy rosszindulatú) 
változások felismerhetőségét. A követelmény különö- 
sen vonatkozik az alkalmazás online letöltődő ele- 
meire. 

A követelmény magáért beszél: amennyiben egy beha- 
toló (vagy pl. vírus) képes az alkalmazás vagy annak 
valamilyen működést befolyásoló elemének módosítá- 


sára, az hamis aláírás előállítását eredmé- 
nyezheti. 

A megoldás az lehet, hogy az alkalmazást 

magát, illetve annak komponenseit (EXE, 

DLL, JAR, stb. állományok) alá kell írni, oly 

módon, hogy azt a futtató környezet képes legyen el- 
lenőrizni. Az online letöltődő elemek (pl. plugin, 
BALE-meghajtóprogram, scriptek) sértetlenségéről és 
hitelességéről szintén gondoskodni kell (pl. SSL kap- 
csolat). Kerülni kell, ha mégis felhasználásra kerül, vé- 
deni kell az összes INI, CFG és egyéb külső állomá- 
nyokat, registry bejegyzéseket. 

A Garantálni kell az alkalmazás által kezelt aláírásspeci- 
fikus adatok sértetlenségét. 

E nélkül egy behatoló az egyes adatokat az alkalmazás 
egyes komponenseiben, illetve az azok közötti kom- 
munikációban módosíthatná. 

A Garantálni kell az alkalmazás és a BALE közti kommu- 
nikáció sértetlenségét. 

Különben egy behatoló az alkalmazás és a BALE közöt- 
ti kommunikációba belenyúlhatna, és azt módosíthatná. 

HA Garantálni kell az alkalmazás adatainak, különösen az 

aktivizáló adatnak a bizalmasságát (az előző követel- 
mény csak a sértetlenségről szólt). 
Amennyiben egy illetéktelen az adatok megismerésé- 
vel bizalmas információk birtokába juthat, a megismert 
aktivizáló adatot később aláíráshamisítására használ- 
hatja fel, amennyiben az aláíráslétrehozó adathoz hoz- 
záfér. 

A Garantálni kell, hogy a felhasználó által kiválasztott 

adatok (pl. aláírandó adat, aláírandó adat alkotóele- 
mek) jelenjenek meg a felhasználó előtt, majd ezek az 
adatok kerüljenek felhasználásra az aláíráslétrehozás 
folyamatában. 
Ha egy behatoló a kiválasztás és megjelenítés, illetve 
a felhasználás folyamatába képes beavatkozni, semmi 
nem garantálja, hogy az aláíró által látott, kiválasztott 
és jóváhagyott adatok kerülnek aláírásra, illetve az 
aláírás során felhasználásra. 


Az aláírandó adat az alkalmazás által létrehozott és ke- 
zelt legkomplexebb objektum, amire vonatkozóan több 
követelménynek is eleget kell tenni. Így például a követ- 
kezőknek: 

A Az aláírandó adatnak tartalmazni kell aláírói dokumen- 
tumot. 

Az aláírás nem jöhet létre egy üres dokumentumra, il- 
letve null értékre. 

A Az aláírandó adatnak tartalmazni kell az aláíró azon ta- 
núsítványát (vagy egy arra történő egyértelmű utalást), 
mely az aláírás készítésében részt vevő aláíráslétre- 
hozó adathoz kapcsolódik (különösen amennyiben 
aláíró több ilyennel rendelkezik). 

Ennek az a célja, hogy ne fordulhasson elő, hogy az el- 
lenőrző aláíró egy másik tanúsítványát használja az 
aláírás ellenőrzéséhez. . 

A Az aláírandó adatnak tartalmazni kell az aláírói doku- 
mentum formátumát, amennyiben az aláírási szabály- 
zat több tartalomformátumot is meghatároz. 

Ne fordulhasson elő, hogy az ellenőrző az aláírói do- 
kumentumot rosszul értelmezi, mert pl. nem megfelelő 
módon jeleníti azt meg. 
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Követelmények komponensenként 


Az aláírói dokumentummegjelenítő feladata a nevében van. A 
komponenssel szemben támasztott követelmények jó része a 
tartalomformátummal összefüggésben értelmezett: 

AA Lehetővé kell tenni a tartalomformátum belefoglalását 
az aláírói dokumentumba, az aláírási szabályzatba 
vagy az aláírásjellemzőkbe. 

A Az aláírói dokumentum megjelenítő által kezelt tarta- 
lomformátumokat ismertetni kell a felhasználókkal. 

Ez történhet a termék csomagolásán, dokumentáció- 
ban, helpben. 

TA Az aláírót figyelmeztetni kell, amennyiben olyan tarta- 
lomformátumot választ, melyet az aláírói dokumen- 
tummegjelenítő nem kezel. 


Mint látható, a követelmények nem kívánnak mindig bonyo- 
lult fejlesztési megoldásokat. Sokszor elégséges lehet egy egy- 
szerű funkció, egy dokumentálás vagy csak egy figyelmeztető 
rendszerüzenet is. Az aláírói dokumentummegjelenítővel 
szembeni további követelmények nem kötődnek a tartalom- 
formátumhoz: 


A Figyelmeztetni kell az aláírót, amennyiben az aláírói 

dokumentum egyéb aláírásokat is tartalmaz, és lehető- 
vé kell tenni az aláíró számára ezen aláírások ellenőr- 
zését. 
Ez a követelmény a többszörös aláírásokkal kapcsolat- 
ban értelmezett, amikor az aláíró egy olyan aláírói do- 
kumentumot ír alá, amin már szerepel mások aláírása. 
Ezek között lehetnek nem valódi vagy nem érvényes 
aláírások is, mely esetben a dokumentum újabb aláírá- 
sát ki kell zárni. 

A Meg kell akadályozni, hogy aláíró az aláírói dokumen- 

tumot a megjelenítés során módosítsa. 
Az aláírói dokumentumot a megjelenítés előtt véglege- 
síteni kell. A komponens tényleg csak a megjelenítésre 
való. Amennyiben a megjelenítés során derül ki a do- 
kumentum valamely hiányossága, az aláírás folyamatát 
meg kell szakítani. A követelmény egyaránt vonatkozik 
a véletlen és szándékos módosítások lehetőségére. 


Az aláírásjellemzők megtekintőre jellemző elvárás az 
alábbi: 
A Lehetővé kell tenni az aláíró számára az aláírásjellem- 
zők közé foglalt tanúsítvány adatainak megtekintését. 


Ennek az a célja, nehogy tévedésből nem megfelelő tanúsít- 
vány kerüljön aláírásra, valamint a hozzá tartozó magánkulcs 
felhasználásra. Jellemző eset például, hogy az aláírónak több 
tanúsítványa is van, amik csak a felhasználási célban külön- 
böznek. Ezek könnyen összetéveszthetők még részletes ada- 
tok alapján is, kivonatos adatok alapján pedig nem is lehet 
őket megkülönböztetni. 


Az aláíró interfészkomponenssel kapcsolatos legnyilván- 
valóbb és legegyszerűbben teljesíthető követelmény a 
következő: 
A Az aláírás végrehajtása előtt az aláíró jóváhagyását kell 
kérni az aláíráshoz. 
Ez azért szükséges, mert meg kell akadályozni azt, 
hogy az aláírás az aláíró akarata ellenére jöjjön létre. A 
jóváhagyást (mely különbözik az aláíró aláíró-eszköz 


felé történő hitelesítésétől), minden egyes aláírás előtt 
ki kell kérni. Célszerű amolyan , utolsó figyelmeztetést" 
alkalmazni, mivel az aláíró nem biztos, hogy tisztában 
van vele, melyik az utolsó lépés, ami után az aláírás 
létrejön. 


Az aláíróhitelesítő komponenssel kapcsolatban hason- 
lóan evidens ez a követelmény: 

A Amennyiben az aláíró meghatározott számú próbálko- 

zás után sem képes az aláíráslétrehozó eszköz aktivá- 
lási adatának helyes megadására, figyelmeztetni kell 
az aláírót, és meg kell akadályozni a további próbál- 
kozásokat. 
A többszöri hibás kísérlet az aktiválási adat megadásá- 
ra próbálkozásos támadásra utal. Célszerű, ha az enge- 
délyezett kísérletek száma konfigurálható a helyi 
előírásoknak és egyéni igényeknek megfelelő módon 
(de ha ilyen konfigurációra mód van, az nem lehet hoz- 
záférhető egy illetéktelen behatoló számára). Az enge- 
délyezett kísérletek túllépése esetén az eszközt blok- 
kolni kell, ami után csak egy másik kóddal (PUK) hoz- 
ható újra normál állapotba. 


Az aláírandó adatformattálóval szemben talán ez az 
egyetlen elvárás: 

A Az aláíró által választott aláírási szabályzatnak megfe- 
lelően kell összeállítani a formattált aláírandó adatot. 
Amennyiben nem így történik az számos félreértéshez, 
könnyen az aláírás ellenőrzésének teljes meghiúsulásá- 
hoz vezethet. 


A lenyomatoló komponenssel szemben számos kriptográ- 
fiai és formátum-megfelelőségi követelmény létezik. Egy 
ilyen az alábbi: 

A Csak azok a lenyomatoló algoritmusok használhatók a 
komponensben, melyek a minősített elektronikus 
aláírások számára elfogadottak. Nem megfelelő biz- 
tonságú lenyomatoló algoritmus felhasználása bizton- 
sági problémákat jelent. 

A hazánkban e célra elfogadott lenyomatoló algoritmu- 
sok listája a 272002. MeHVM irányelv 1-es számú mel- 
lékletében találhatók meg. j 


A BALE-kommunikátorral szembeni elvárások közül az 
alábbi egy elsősorban funkcionális kívánalom: 

A Biztosítani kell annak lehetőségét, hogy az aláíró a 
BALE-n tárolt alkalmazások, aláíráslétrehozó adatok és 
egyéb aláírásjellemzők közül az általa felhasználni kí- 
vántat választhassa ki. Az alkalmazások közül csak a 
relevánsak kiválasztását szabad engedélyezni, a kivá- 
lasztott tanúsítványnak megfelelő aláíráslétrehozó adat 
használatát biztosítani kell, s az aláírásjellemzőkkel 
kapcsolatos szabályok kezeléséről is gondoskodni kell. 
A követelmény olyan esetben releváns, mikor a BALE-n 
több aláíráslétrehozó adat, és ezekkel összefüggésben 
több aláírásjellemző is tárolódik, illetve amennyiben 
multiapplikációs BALE-ról van szó. Ilyen esetben egy 
nem megfelelő, vagy az aláíró által felhasználni nem 
kívánt alkalmazás vagy aláíráslétrehozó adat kiválasz- 
tása nem megfelelő aláírás előállítását és egyéb hibákat 
eredményezhet. 


Az aláírói dokumentumösszeállítóval kapcsolatban nincsenek 
követelmények explicit megfogalmazva, de az általa előállí- 
tott dokumentumokon és azok kezelésén keresztül igen. Így 
áttételesen követelmény, hogy olyan formátumú dokumentu- 
mokat legyenek képesek előállítani, amit az alkalmazás 
aláírói dokumentum megjelenítő komponense képes az aláíró 
számára az eredeti formájában megjeleníteni. Az előállított 
dokumentum megfelelőségének tesztelése az aláírói doku- 
mentum- és aláírásjellemzők megjelenítő komponensek 
feladata. 


Az aláírt adathalmazösszeállítóval kapcsolatos alábbi 
követelmény nyilvánvaló, de nem könnyen teljesíthető: 
HA Gondoskodni kell arról, hogy az aláírt adathalmazban 
lévő minősített elektronikus aláírás érvényessége a 
szintén az aláírt adathalmazban szereplő adatok alap- 
ján megállapítható legyen. 


Az aláírt adathalmaz formátuma nem feltétlen képezi le pon- 
tosan a formattált aláírandó adatot. Ezért az aláírt adathalmaz- 
nak tartalmazni kell az aláírás elkészítésében szerepet kapó 
összes adatot, vagy az ezekre történő egyértelmű utalást, va- 
lamint a formattált aláírandó adat típusát, hogy az aláírásel- 
lenőrző alkalmazás képes legyen azt az aláíráslétrehozó alkal- 
mazáshoz hasonlóan összeállítani. 


Az Aláírásnaplózó komponenssel szembeni következő 
pont ajánlásnak tekinthető: 

Hi Lehetőség szerint lehetővé kell tenni aláírónak, hogy 
az aláíráslétrehozó eszköz felhasználását nyomon tud- 
ja követni. 

Ez naplózási és naplómegtekintési funkciók biztosítá- 
sán keresztül történhet meg. 





A szolgáltatói együttműködő komponenssel szembeni 
legfőbb elvárás, hogy: 
H Az alkalmazásnak képesnek kell lenni tanúsítványok 
szolgáltatótól történő letöltésére és hitelességük, vala- 
mint érvényességük ellenőrzésére. 


A BALE-tulajdonos kijelzővel szembeni egyetlen követel- 
mény az alábbi: 
IH Gondoskodni kell a BALE-tulajdonos azonosító kijel- 
zéséről, amennyiben ilyen adat rendelkezésre áll. 
Ez azért szükséges, hogy az aláíró ellenőrizhesse, hogy 
valóban a saját eszközét használja. A felirat nélküli esz- 
közöket (pl. USB tokenek) könnyű elcserélni egy cégen 
belül, ahol mindenkinek ugyanolyan kütyüje van. 


Almási János 
CIO 
Almasi-Janosádbrt.hu 





Minősített elektronikus aláírás 

Olyan fokozott biztonságú elektronikus aláírás, amely 
biztonságos aláíráslétrehozó eszközzel készült, és mi- 
nősített tanúsítványon alapul. 


Fokozott biztonságú elektronikus aláírás 
Elektronikus aláírás, amely alkalmas az aláíró azono- 
sítására és egyedülállóan hozzá köthető; valamint 
olyan eszközökkel hozták létre, amelyek kizárólag az 
aláíró befolyása alatt állnak; és a dokumentum tartal- 
mához technikailag olyan módon kapcsolódik, hogy 
minden - az aláírás elhelyezését követően az iraton, 
illetve dokumentumon tett — módosítás érzékelhető. 


Elektronikus aláírás szolgáltatások 
A jogszabályok a következő elektronikus aláírás szol- 
gáltatásokat definiálják: 


ma (elektronikus aláírás) hitelesítésszolgáltatás 

HA időbélyegzés 

mA aláíráslétrehozó eszközön az aláíráslétrehozó 
adat elhelyezése 


Hitelesítésszolgáltatás 

A hitelesítésszolgáltatás keretében a hitelesítésszol- 
gáltató azonosítja az igénylő személyét, tanúsítványt 
bocsát ki, nyilvántartásokat vezet, fogadja a tanúsítvá- 
nyokkal kapcsolatos változások adatait, valamint nyil- 
vánosságra hozza a tanúsítványhoz tartozó szabály- 
zatokat, az aláírás-ellenőrző adatokat és a tanúsítvány 
aktuális állapotára (különösen az esetleges visszavo- 
nására) vonatkozó információkat. 


Megbízható útvonal 

Az aláíráslétrehozó rendszer hardver és szoftver alko- 
tóelemein áthaladó útvonal, mely garantálja minden 
rajta keresztül továbbított adat integritását, hitelessé- 
gét és bizalmasságát. Az egyes interfészkomponen- 
sekhez szükséges, mint az aláírói interfész és a BALE- 
kommunikátor. 





nAzt írsz alá, amit látsz" 

Elv, melynek érvényre jutása garantálja, hogy az 
aláíró valóban az általa látott aláírandó dokumentu- 
mot írja alá. 


nAzt lett aláírva, amit látsz" 

Elv, melynek érvényre jutása garantálja, hogy az el- 
lenőrző valóban azt a dokumentumot látja, ami alá 
lett írva, abban a formában, ahogy az aláíró is látta. 


- asatizsag [AIUA] SEZEMIEYIR OTAZAYSEITETE SOGESNOTZIA / 
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Elliptikus görbe 
kriptorendszerek II. TÉsz 


Elliptic Curve Cryptography - algoritmusok 


és a gyakorlat 


Egy jó ideje egyre több helyen találkozhatunk az ECC betűhármassal, mint egy kriptorendszer 
jelölésével. A cikk első részében áttekintettük e viszonylag fiatal kriptorendszer elvi alapjait, most 


jöjjön néhány gyakorlati példa és algoritmus! 


Remélem az első rész senkit nem rettentett el az ECC-től és az 
elmúlt egy hónap mindenkinek elég volt ahhoz, hogy a kissé 
száraz előkészítést magáévá tegye. Lássunk néhány algorit- 
must, melyek rettentően hasonlítanak néhány meglévőre... 


Titkosítás és aláírás az elliptikus görbékkel 


Az ECDLP-n alapuló rendszerek többsége aláíró (például 
ECDSA) vagy kulcscserélő (például ECDH) rendszer, mert 
gyors titkosításra ez a módszer is alkalmatlan, hasonlóan a 
többi nyíltkulcsos algoritmushoz. A továbbiakban eme algorit- 
musokkal ismerkedhetünk meg. (A folytatás jobb megértésé- 
hez ajánlott ismeretek: Diffie-Hellman kulcscsere, ElGamal 
titkosítás valamint az üzenetpecsét algoritmusok ismerete — 
legalább nagyvonalakban. Ezek nélkül is érthető lesz a folyta- 
tás, csak nehezebb lesz párhuzamot találni a már meglévő al- 
goritmusok és az EC-alapú algoritmusok között...) 


ECDH - Elliptic Curve Diffie-Hellman kulcscsere 


Az eredeti Diffie-Hellman a szimmetrikus titkosító rendszerek 
kulcsmegosztási problémáját oldatta meg. Hogyan is? A két 
résztvevő ugyanazokat a műveleteket végezte el egyező nyil- 
vános és különböző titkos paraméterekkel, de azonos ered- 
ményt kaptak, melyet kulcsként használhattak. Az ECDH is 
ugyanígy működik, csak nem moduláris hatványozást hasz- 
nál, hanem a korábban megismert EC-műveleteket. 

Alice és Bob megegyeznek egy E görbében és egy G pontban, 
utóbbit bázispontnak hívjuk. A továbbiakban eme paraméte- 
reket nyilvános rendszerparamétereknek tekintjük. Alice vá- 
laszt egy véletlen számot, (amely kisebb, mint a G pont rend- 
je) és ugyanígy tesz Bob is: Alice száma legyen a, Bobé legyen 
b. Mindketten titokban tartják választásukat. A kulcscsere kö- 
vetkező lépésében Alice kiszámolja a"G pontot, melyet elküld 
Bobnak, aki Alice műveletéhez hasonlóan kiszámolja b"G 
pontot és elküldi Alicenak. Végül Alice a Bobtól kapott btG-t 
megszorozza a-val, így megkapja atb"G pontot, valamint Bob 
az Alice-tól kapott atG pontot szorozza meg saját titkos b szá- 
mával, és eredményül ő is az atb"G pontot kapja. 

A közös pont valamely tulajdonsága (például x vagy y koordi- 
nátája vagy éppen x 4 y) használható kulcsként. A kíváncsi 
Eve-nek az abG pontot kellene kiszámolnia, de csak G, aG és 
bG pontokat ismeri, magukat a titkos a és b számokat nem. Az 
elliptikus Diffie-Hellman működését és lépéseit az alábbi egy- 
szerű számpélda alapján követhetjük: 





ECEIGamal - Elliptic Curve EIlGamal titkosítás 


Ahogy az eredeti ElGamal titkosítás a Diffie-Hellman algorit- 
mus problémáján alapul, úgy építhető fel az elliptikus 
ElGamal is az ECDH-ra: 

1. Alice és Bob választ egy E görbét és egy G bázispontot. 

2. Mindketten választanak egy-egy véletlen a és b számot, 
mint titkos kulcsot. 

3. Alice elküldi az atG pontot, mint nyilvános kulcsot 
Bobnak. 

4. Bob elküldi a btG pontot, mint nyilvános kulcsot Alice- 
nak. 

5. Ha Alice üzenni akar Bobnak, az üzenetet leképzi a 
görbe egy vagy több M pontjára és generál egy véletlen 
k számot, mint viszonykulcsot. Elküldi Bobnak a (kG, 
M--k(bG) ) üzenetpárost. 

6. Bob a következőképpen olvassa el az üzenetet: a ka- 
pott küldemény első felét megszorozza saját titkos b 
számával, így bkG-t kap, amit egyszerűen kivon a kül- 
demény második feléből. 


Eve támadásának feltétele az lenne, ha Bob átküldött nyilvá- 
nos kulcsából ki tudná számolni b értékét vagy a titkosított 
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üzenet első részéből k számot. Jelenlegi ismereteink szerint 
egyikre sem képes elfogadható időn belül. 


ECDSA - Elliptic Curve Digital Signature Algorithm 


A következő algoritmus a FIPS 186-2-ben leírt DSA-hoz ha- 
sonlóan működik, hasonlóak a végzett műveletek, lépések is. 
Ahhoz, hogy Alice egy M üzenetet aláírva el tudjon küldeni, 
a következő paraméterek és eszközök szükségesek: 
1. egy elliptikus görbe mod g felett (nyilvános paraméter) 
2. egy G bázispont, melynek rendje n (nyilvános paramé- 
ter, n 3 160 bit) 
3. egy véletlen d szám (mely kisebb, mint n-1) és egy 
0-dG pont. Alice kulcspárja (d,O), ahol d a titkos és 9 
a nyilvános kulcsa. 


Az ECDSA aláíró algoritmusa 


1. Alice választ egy k számot 1 és n-1 között 

2. Kiszámolja kG-(xy, yj) pontot és r-xi mod n. Ha a pont 
x koordinátája zérus (x,—0), akkor új k számot választ. 
A pont x koordinátája lesz az aláírás egyik komponen- 
se, ezért jelöltük meg külön egy r betűvel. 

3. Kiszámolja k multiplikatív inverzét n-re (vagyis k" mod 
n értékét). 

4. Kiszámolja a küldendő üzenet pecsétjét, melyre a 
szabvány az SHA-1 algoritmust ajánlja. Legyen hát e — 
SHA-1(M)! 

5. Az aláírás másik alkotóeleme a következő kifejezés: 
szk"(e 4 dr) mod n. Abban a szerencsétlen (és megle- 
hetősen ritka) esetben, ha s-0, akkor az egész algorit- 
must elölről kell kezdeni. Itt azt is láthatjuk, hogy a 2. 
lépésben miért nem lehet r-O, mert az aláírás nem tar- 
talmazná a titkos kulcsot! 

6. AzM üzenethez és Alice-hoz tartozó aláírás: az (r,5) ér- 
tékpáros. 


Az ECDSA ellenőrző algoritmusa 


Feltételezzük, hogy Bob, mint az aláírás ellenőrzője rendelke- 
zik a hitelesített(!) rendszerparaméterekkel és Alice hiteles 
nyilvános kulcsával. Bob a következő lépések végrehajtásával 
ellenőrizheti egy aláírás helyességét: 
1. Ellenőrzi, hogy az (r,5) egész számok megfelelő inter- 
vallumban vannak-e? (Kisebbek-e n-1-nél?) 
2. Kiszámolja a kapott üzenet pecsétjét. Ehhez ugyanazt 
az algoritmust kell használnia, amit Alice használt: e — 
SHA-1 (AM. 
3. Kiszámolja s multiplikatív inverzét n-re: w — 5" mod n. 
Ezért nem hagyhattuk az aláírás 5. lépésében, hogy 
s-0 legyen: nem létezne inverze! 
4. Kiszámolja a következő részeredményeket: uj-ew 
mod n és us-rw mod n. 
5. Végül kiszámolja a P(xy,y) — uj G -- u. O elliptikus pon- 
tot. Ha P-O, akkor biztosan nem jó az aláírás, egyéb- 
ként legyen v — xi! 
6. Bob az aláírást csak akkor fogadja el, ha v — r . 


Miért helyes az ellenőrzés? 


Az aláírás-ellenőrzés helyességéhez az kell belátnunk, hogy 
az 5. pontban kiszámolt P pont nem más, mint az Alice által 


kiszámolt kG pont (aláírási folyamat második lépése). 
Alice aláírásának egyik része a következő kifejezés: 


s z kö(e 4 dr) mod n 


Ha az egyenlet mindkét oldalát megszorozzuk s7k szorzattal, 
akkor azt kapjuk, hogy 

k s7"(etidr) 

$  s7e 4 s7dr 

B we 4 wdr 

B u, 4 udd (mod n) 

Már csak egy lépés választ el attól, hogy a Bob által kiszámolt 
P pontra belássuk állításunkat: 

P(xiY1) — ujG 4 u0 - 


—$6 ujG 4 uzdG z ? 
5 (u, 4 uzd)G - kG 


Vagyis, ha Bob a számítás eredményeképpen Alice véletlen 
pontját kapja vissza, azok x koordinátáinak is meg kell egyez- 
niük. Ha Bob egy másik pontot kap eredményül, az aláírás 
nem fogadható el. 


Pontok, görbék előállítása 


Egy-egy ECC-rendszerhez szükség van egy E görbére, egy G 
bázispontra, véletlen pontokra stb. Az alábbiakban ezek előál- 
lítására láthatunk módszereket. Sajnos a görbék és pontok vá- 
lasztásánál sok olyan tulajdonságra kell figyelni, amelyekről 
már volt szó, vagy eddig nem tértem ki rájuk és nem is fogok, 
azok komplexitása miatt. Ha ezen ismeretek hiányában kívá- 
nunk üzleti célú biztonságos implementációt készíteni,-a szab- 
ványokban javasolt görbékből és bázispontokból válasszunk! 
Ne feledjük: ezek egyébként is nyilvános paraméterek! Például 
a [sec] linken elérhető ajánlásokban 113 bittől 571 bitig talá- 
lunk paramétereket, [fedstd] ajánlásban pedig a szabványos- 
nak tekintett bitméretekre: 112, 128, 160, 192, 224, 256, 384, 
521 bit. Úgy vélem, hogy az ECC alapteremtő magyarázatához 
és megértéséhez nem szükségesek a most , elfelejtett" tulajdon- 
ságok, akit pedig érdekel, az Interneten is tengernyi irodalmat 
találhat. (Személy szerint az IEEE P1363 szabványt ajánlom, én 
ebben találtam a legtömörebb, legegyszerűbb és 
, legimplementáció-barátabb" leírásokat.) Kérem a Kedves Ol- 
vasót, hogy nézze el ezt a hiányosságot nekem, de csak és ki- 
zárólag az ECC matematikai hátteréről több könyvet lehetne ír- 
ni. És még néhányat a kriptográfiai alkalmazásukról, gyakorla- 
ti implementációikról... Csak két példa , elrettentésül": 

1. Minden eddig leírt definíciót, szabályt és algoritmust 
még legalább kétszer le lehetne írni, mert az elliptikus 
görbéket nem csak a természetes számok (mod p) felett 
lehet értelmezni, hanem polinom-algebra alapján is, 
amelynek legalább kétféle ábrázolásmódja ismeretes. 
(Ilyenkor a modulus nem egy prímszám, mint eddig, 
hanem egy kettőhatvány. Szoítvermegvalósításban ál- 
talában az előbbi, hardveres megoldásban az utóbbi a 
gyorsabb.) 

2. A kedvelt és szemléletes Descartes-féle koordináta- 
rendszer mellett az elliptikus görbe pontjait a projektív 
síkon is szokták ábrázolni. Ekkor a végtelenben lévő O 
pont az origóba kerül. 


Görbekészítés 


A görbék készítésére egyébként legalább háromféle módszer 
van. Az egyik speciális görbékkel dolgozik, amelyek együtt- 


" KKKRKRKEKK/ 
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hatói bizonyos szempontoknak megfelelnek: opti- 

mális hardvermegvalósítást tesznek lehetővé, vagy 

különlegesen ellenállóvá teszik a görbét valamelyik 

támadási forma ellen, stb. A második szerint a gör- 

béket meghatározó együtthatókat véletlenszerűen 
választjuk meg: 


Válasszunk egy prímszámot: 
p z 4294967861 (274565) 
Majd egy véletlen a paramétert: 
a - 1234567890 
És egy véletlen b paramétert: 
b - 0987654321 
Ellenőrzés következik: 
4a" 4 27b?" mod p - 7526705513494068003917494107 
mod 4294967861 - 1240368550 zs 0 2 OK! 
A kész görbénk egyenlete: 
y zs x" 4 1234567890x 4 987654321 (mod 429467861) 


A harmadik módszer nem véletlen számokat használ, hanem 
egy kezdőértékből (seed) számított SHA-1 érték alapján állítja 
elő az együtthatókat. Az IEEE P1363 és a NIST egyaránt ezt az 
eljárást ajánlja az ilyen típusú görbék (pseudo-random curves) 
konstruálásához [fedstd]. Az álvéletlen megoldás előnye, 
hogy reprodukálható és így ellenőrizhető, hogy egy görbe ez- 
zel a módszerrel készült-e vagy sem. 


Pontkészítés 


Ha már van egy görbénk, azon egy véletlen pontot is kereshe- 
tünk. Példaképpen a véletlen számokból készített görbénken 
keresünk egy pontot: 


y z x41234567890x41987654321 (mod 429467861) 

x - 147896325 (véletlenszerűen választott) 

y" s 370713451 (mod 4294967861) 

v:? 

Hát, izé... ennek nincs megoldása, vagyis nincs olyan szám, 
amelynek négyzetét a modulussal elosztva 370713451-et 
kapnánk maradékul. Próbáljuk meg újra egy másik x értékkel! 
x - 225589 


y" z 376919525 (mod 4294967861) 
y - 57372704 


Na, ezzel megvolnánk: P(225589, 57372704)! E pontnak van 
még néhány tulajdonsága, amit jó lenne tudni (például gene- 
rátor-e? Ha nem, mennyi a rendje?), de ezekkel most nem fog- 
lalkozunk (lásd korábban, hogy miért nem). 


Üzenet leképzése egy pontra és vissza 


Néhány kriptográfiai algoritmus tartalmaz egy olyan lépést, 
amikor az üzenetet le kell képezni egy olyan alakra, amit az 
adott algoritmus kezelni tud. Esetünkben ez azt jelenti, hogy 
egy adott E görbe alkalmazása mellett Alice P ponttá tudja ala- 
kítani az m üzenetet és Bob egy megoldott pontból ki tudja 
venni az üzenetet. (Itt jegyzem meg: előfordulhat, hogy csak a 
pont x koordinátája közlekedik teljes egészében a kommuni- 
kációban. Az y-nak csak legnagyobb helyértékű bitje kíséri az 
x-et, mondván, az y kiszámolható. Ebben az esetben a pontot 
tömörített pontnak (compressed point) hívja az ANSI9.62, az 
IEEE P1363 és a SEC is. A három forrás legnagyobb különbsé- 
ge, hogy a SEC csak használja a fogalmat, a többiek el is ma- 
gyarázzák.) 

A példához ismét a korábban készített görbénket fogjuk hasz- 
nálni. Első próbálkozásunkkal alakítsuk ponttá a ,Jó!" karak- 
tersorozatot! Ehhez először számmá kell alakítani: a karakte- 


rek ASCII kódját hexa formában egymás mellé írjuk és egyet- 
len hexadecimális számként értelmezzük. Más módszer is 
használhatunk, a lényeg, hogy: 
AA kölcsönösen egyértelmű megfeleltetés legyen, 
FA a blokkméretnek kisebbnek kell lennie, mint a modu- 
lus hossza! 


És ezután mi sem egyszerűbb, ez legyen az üzenetet képvise- 
lő P pont x koordinátája, csak ki kell számolni a hozzátartozó 
y-t! Lássunk neki! 


m - ,Jó!" - OxX4A 0xF3 0x21 - 0Ox4AF321 - 4911905 
P(m,y) - (4911905, ?) 

y z x 4 1234567890x 4 987654321 (mod 429467861) 
y zs 43578828 

y z 165701469 

P(m,y) -  (4911905, 165701469) 


Természetesen felvetődhet a kérdés, hogy mi van akkor, ha az 
üzenet alapján nem létezik pont? A pontgenerálás első próbál- 
kozása is ezért volt sikertelen. Mi a teendő akkor, ha y2-nek 
nincs megoldása? 


m z- ,Nem" - 0x4E 0x65 Ox6D - 0x4E656D - 5137773 
P(m,y)"z (51377737 ?) 

y z x" 4 1234567890x 4 987654321 (mod 429467861) 
y s 109210672 

y s nincs megoldása 


Az ilyen esetekre felkészült alkalmazások nem tisztán az m 
üzenetet tekintik az x koordinátának, hanem az x koordináta 
felső bitjeibe helyezik el azt, majd az alsó bitekkel addig ,szó- 
rakoznak", amíg eredményre nem jutnak: P(m " eltolás 4 va- 
lami, y). Ilyenkor az üzenetet kibányászni a (P, / eltolás) 
egészrészeként lehet. Példánkban a modulus 29 bites, az elto- 
lás legyen 6 bit, így 23 bites üzeneteket tudunk továbbítani. 
Próbáljuk meg még egyszer a , Nem" szót ponttá alakítani, az 
eltolás használatával (valami-10, ha nem jutunk eredményre, 
majd választunk másikat... 


m z ,Nem" - 0x4E 0x65 Ox6D - 0x4E656D - 5137773 
P(mt2"410,y) -  (328817482, ?) 

y 2 x411234567890x4987654321 (mod 429467861) 

vy zs 275000646 . 

y zs 125641602 

P(328817482, 125641602) 


Ezt a pontot már Alice tetszőleges módon titkosíthatja és el- 
küldheti Bobnak. Bob a dekódolás után szerencsés esetben 
ezt a pontot fogja visszakapni. Megragadja a pont x koordiná- 
táját, elosztja 2"-nal és az eredmény egészrésze: 5137773 ! 
Voilá! 


Tényleg biztonságban vagyunk? 

A kérdés megválaszolásához a bevezetőben szereplő gondo- 
latokat kell továbbfűznünk az eddigi törési kísérletek és ta- 
pasztalatok fényében. 


Certicom challenges 


Az RSA Inc.-hez hasonlóan a Certicom Corporation 
[certicom)] is írt ki törési versenyeket, melyek egy része mára 
megoldott, másik része még megoldásra vár [certchall]. A 
feladatok 1999 óta — a Certicom szándéka szerint — azt kíván- 
ják bizonyítani, hogy az ECC erősebb, mint az RSA- vagy a 
DLP-probléma. Másrészt marketingfogás, amely megpróbálja 
a potenciális ipari felhasználók, fejlesztők és a kutatók figyel- 


mét az ECDLP felé terelni. A versenykiírásban mintegy 20 
nyilvános kulcs szerepel, a hozzájuk tartozó rendszerparamé- 
terekkel együtt [curlist]. A feladat: meg kell keresni a titkos 
kulcsot! 

A Certicom az alábbi három csoportra osztotta a feladványo- 
kat (zárójelben a Certicom által becsült megoldási idők, né- 
hány ezer együttműködő gép esetére): 





Excercises: [ 79 bites ] (néhány óra) 
89 bites ] (néhány nap) 
(0 ] 97 bites ] (néhány hét) 
Level I: 109 bites ] (néhány hónap) 
131 bites ] (néhány hónapnál sokkal több) 
Level II: 163 bites ] (jelenleg megoldhatatlan feladatok) 
191 bites 
239 bites 
359 bites 


Eddigi megoldások néhány technikai adatát tartalmazza a kö- 
vetkező felsorolás. (Érdekes, hogy a különböző források kis 
mértékben ellentmondóak egymásnak, akárcsak az RSA töré- 
si versenyek esetében...) 

2002. November 6. — ECCp-109 Challenge megoldása (prím 
modulus): 10300 résztvevő, 10000 számítógép, 1,5 év időtar- 
tam; 

2000. Április 17. - ECC2K-108 Challenge megoldása 
(kettőhatvány modulus): 1300 résztvevő, 9500 számítógép, 4 
hónap időtartam; 

1999. Szeptember 28. — A 97-bites ECC Challenge megoldá- 
sa: 200 résztvevő, 740 számítógép, 16000 MIPS-év számítás- 
igény. Mindez körülbelül fele az ötször hosszabb RSA-512 fel- 
töréséhez használt teljesítménynek. 


Pollard-p algoritmusa 


Napjaink legjobbnak tartott algoritmusa a Pollard-p algorit- 
mus (Pollard-ró). Az eljárás kis módosítással teljes mértékben 
párhuzamosítható, így ha 10 processzor áll rendelkezésre, 10- 
szer gyorsabban jut eredményre. Ha csak egy processzorunk 
van, 0.5"v(srtp) EC-összeadás (ahol p a modulus) kell a végre- 
hajtásához, ha több, akkor ez a sok számítás megoszlik köz- 
tük. Akármilyen jó is az algoritmus, tetemes számításigénye 





van: 

p mérete Mega 

97 bit F-ágy 1,6x107 

160 bit e 8,5x10" 

186 bit E al ZA 

234 bit 207 12x107 
354 bit 9:sznóstllltltlllt Tá 0 
426 bit e 9.2x10" 


Összehasonlításul a faktorizálás becsült számításigénye a szo- 
kásos modulusok méretére: 


modulus mérete hl exot 





512 bit 3x10 
768 bit 2x10" 
1024 bit ——3x10" 
1280 bit — (0 110" 
1536 bit 3x10" 
2048 bit (—3x10" 


(1 MIPS-év az a számításigény, ami 1 darab 1 MIPS 
teljesítményű számítógéppel 1 év alatt teljesíthető.) 


Az algoritmus további részleteitől és hátterétől most 
nagyvonalúan tekintsünk el, jelentősen túlmutat a 
cikk célkitűzésein. 


Válasz a kérdésre: nem tudjuk! 


Napjaink minden széles körben elterjedt kulcscserére, titkosí- 
tásra vagy digitális aláírásra használt PKI algoritmusa a 
faktorizálás vagy a diszkrét logaritmus problémáján nyugszik. 
A két probléma hasonlít egymáshoz, amit az is jól jelez, hogy 
a legjobb faktorizáló algoritmusok (bizonyos feltételek teljesü- 
lése esetén) felhasználhatók a DLP-problémák megoldásában 
is. Némi egyszerűsítéssel azt is mondhatjuk, hogy egyező 
kulcsméret mellett egyező biztonságot nyújtanak. 

Sajnos a DLP és az ECDLP már nem hasonlít ennyire egymás- 
ra, a viszonylag jó és újabb DLP-megoldó algoritmusok (, in- 
dex kalkulus") egyszerűen nem használhatók ECDLP esetére: 
ott meg kell elégedni a régebbi módszerekkel (például 
Pollard-p). Ebből az is következik, hogy elégséges, ha a kul- 
csok e régi és lassú ,trükköknek" ellenállnak, tehát rövideb- 
bek is lehetnek. Jelentősen rövidebbek. A minimálisan ajánlott 
kulcsméret ma 1024 bit az RSA esetében, 163 bit az ECC- 
rendszerekhez. 

Semmi sem garantálja azonban, hogy ez holnap is így lesz. 
Semmi sem garantálja, hogy a közeljövőben valaki nem pub- 
likál egy olyan eljárást, amely valóban jó megoldást nyújt az 
ECDLP-re. Nem tudjuk, hogy elvileg sem működnek a DLP jó 
algoritmusai vagy csak a mi ismereteink a hiányosak. Igazság 
szerint az ECDLP-re ma is léteznek jó algoritmusok, de ezek 
mindegyike kizárólag valamilyen speciális tulajdonságú gör- 
bére és nem általánosan alkalmazható. Jelenlegi tudásunk 
szerint mindenestre az ECDLP alapú kriptorendszerek jobbak 
— gyorsabbak és biztonságosabbak -—, mint az IFP-n vagy a 
DLP-n alapuló kriptorendszerek [menezesl]. 


Virasztó Tamás 
wachergwestel900.net 


A cikkben szereplő URL-ek a 





http://technet.netacademia.net/go?kulcsszó címen érhetők el. 
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AZ WUNML 


1-1! Objektumorientált 


a  alkalmazásfejlesztés 


Sok szó esett már az UML-ről, és talán még mindig vannak, akik számára nem 
egyértelmű, mit is takar ez a három betű tulajdonképpen. Számukra szeretnék egy 
kis segítséget nyújtani, hogy tisztább legyen a kép, és ne rémüljenek meg, ha egy 


osztálydiagram feltűnik valahol. 


Az elmúlt hónapban néhány szóban igyekeztem bemutatni az 
objektumorientált világot, az OO fejlesztés szükségességét és 
létjogosultságát. Az ott felsorolt fogalmak, rövidítések nem vá- 
laszthatók el szervesen egymástól, most mégis igyekszem 
egyet kiemelni közülük — ez pedig az UML lesz. 

Láttuk, hogy a szoftverkrízis megoldásaként az objektum- 
orientált programozás megjelenése szolgált. Ez azonban újfaj- 
ta szemléletet jelentett, így újabb és újabb tervezési módsze- 
rekre volt szükség. Felismerték, hogy nagy és bonyolult rend- 
szereket csak hatékony módszerekkel lehet tervezni és fejlesz- 
teni. Olyan, a tervezés és fejlesztés során egységesített techni- 
kákra van tehát szükség, amelyek segítségével a folyamat 
nemcsak gyorsabb, de átláthatóbb, kezelhetőbb, ezáltal sok- 
kal eredményesebb is lesz. 

A "70-es évek közepétől így folyamatosak voltak azok az erő- 
feszítések, amelyek alternatív elemzési és tervezési módszere- 
ket kerestek. Számos megoldás született, többségük azonban 
nem volt alkalmas arra, hogy a gyakorlatban is elterjedjen. 
Az áttörés a "90-es évek elején történt, amikor olyan új gene- 
rációs, a szoftver teljes életciklusát átfogó, hatékony módszer- 
tanok láttak napvilágot, amelyek számos projektben eredmé- 
nyesnek bizonyultak. Néhány példa ezek közül: OMT, 
Booch"94, Coad-Yourdon, Fusion stb. A sokféle módszertan 
közül nehéz volt választani, hiszen mindegyiknek megvolt a 
maga erőssége és gyengesége egyaránt. Egyre sürgetőbbé vált 
az egységesítés. A különféle módszerek különféle jelölésmó- 
dot alkalmaztak, ami igencsak megnehezítette a fejlesztők 
dolgát, akik projektenként mást voltak kénytelenek megtanul- 
ni. Ugyancsak nehézkes volt így a fejlesztők és felhasználók 
közötti kommunikáció is. 

Ezen igényeket és hiányosságokat felismerve tűzte ki célul egy 
egységes módszertani és modellezési megoldás kidolgozását 
James Rumbaugh (General Electric), Ivar Jacobson (Objectory 
AB) és Grady Booch (Rational Software Co.), akik a korábbi 
módszerek vezető fejlesztői voltak. Korábbi, külön-külön 
megszerzett tapasztalataik alapján ki akarták szűrni azokat a 
hátulütőket, amelyekkel munkájuk során találkoztak, és az 
egységesítéstől egyfajta stabilitást vártak az OO tervezési- 
elemzési módszerek piacán. 

Az UML-ig (és a RUP-ig) vezető út csaknem 10 évig tartott, fo- 
lyamatát az alábbi, Booch-tól kölcsönzött ábra mutatja: 










Rational Unified Process 5.0 
(1998) 


Nu 
A Rational Software Co. Rational Objectory Process 4.1 Egyéb módszertanok 
módszertani 1996-1997 1997-1998 

megközelítése 


Objectory Process 1.3 - 3.8 
1987-1995 UML 1994-1997 


Unified Language 





Ericsson fejleszt ések 


7 A UP kifejlesztésének folyamata 


Az egységesített módszertan tehát a RUP (Rational Unified 
Process) nevet kapta, fejlesztése 1998-ban ért véget. A mód- 
szertan az UML-t használja modellező nyelvként, és az általa 
definiált folyamat alapvetően iteratív jellegű: a tervezési/fej- 
lesztési folyamat ismétlődő iterációkból áll, amelyek során a 
rendszer kidolgozottsága egyre finomabbá válik. 

Most azonban nem célom ezt a folyamatot részleteiben be- 
mutatni, ,csupán" az UML-ről mint modellező nyelvről sze- 
retnék írni néhány hasznos dolgot. Mindezt igyekszem úgy 
megtenni, hogy a kezdők számára is érthető legyen, az UML- 
ben járatos szakemberek pedig egyfajta áttekintést kaphatnak 
majd. 


Az UML története 

A "90-es évek elején már felmerült az igény egy vizuális mo- 
dellező nyelv kialakítására, az érdemi munka azonban csak 
1994-ben kezdődött, amikor Rumbaugh csatlakozott a 
Rational csapatához, és Booch-hal együtt kidolgozták az 
1995-ben publikált Unified Method elnevezésű módszertant, 


amelyet tulajdonképpen az UML (Unified Modelling 
Language) 0.8 verziójának tekinthetünk. 

Az UM nyilvánossá tétele után csatlakozott a csoporthoz 
Jacobson, aki újabb előnyös elemek felvételét javasolta az 
UM-hez. Sok elem került tehát a régebbi módszertanokból az 
UM-be, ugyanakkor sok olyan újdonság is megjelent, amely 
korábban sehol nem volt megtalálható. Az újabb és újabb 
elemek hozzáadásával egyébként igen óvatosan bántak, hi- 
szen nem akarták feleslegesen túlbonyolítani az új megol- 
dást. 1996-ban jelent meg az UML 0.9, amelyet már ki is ad- 
tak különböző fejlesztő csapatoknak tesztelés céljából: hasz- 
nálják ezt a modellező nyelvet, és tapasztalataikat osszák 
meg, hogy azok felhasználhatók legyenek a későbbiekben. 
Ezek a kísérletek sikeresek voltak, és sok. cég innen kezdve 
már kizárólag az UML-t használta (és használja). Az OMG 
1997 végén fogadta el az UML 1.1 verzióját, amelynek fej- 
lesztésébe már különböző neves cégek is bekapcsolódtak 
(IBM, Microsoft, HP, stb.). 

A nyelv hiányosságai és problémái azonban — mint általában 
— most is a használatbavételt követően jelentkeztek igazán. 
Egy nyelvet azonban nem célszerű túl gyakran váltogatni, hi- 
szen idő kell egyrészt annak elsajátításához, másrészt a hasz- 
nálatát támogató CASE eszközök kifejlesztéséhez is. Eltérő vé- 
lemények vannak arról, hogy melyik irányba ildomos eltolni a 
hangsúlyt (a folyamatos frissítést vagy a stabilitást tartsuk-e 
szem előtt). Rumbaugh szerint egy lehetséges és hatékony, 
kompromisszumos megoldás az, ha 4-5 évente felülvizsgáljuk 
és frissítjük nyelvet. 

Az UML-lel kapcsolatos észrevételek elsősorban a kiterjeszt- 
hetőségre, a feltételek megfogalmazásának módjára, a nyelv 
struktúrájára és a diagramok közötti átjárhatóságra vonatkoz- 
tak. A tervek szerint 2001 végére készült volna el az új nyelv 
dokumentációja, és 2002 elején fogadták volna el a végleges 
verziót. Némi csúszással mindez nemrég történt csak meg, 
ezért cikksorozatomban elsősorban a , régi" UML elemeit mu- 
tatom be, és külön térek majd ki az UML 2.0 újdonságaira, a 
bekövetkezett módosításokra és változásokra. 






Az UML elemei 


Az UML-ről és a használatáról korábban már írtam egy cikk- 
sorozatot. Úgy gondolom azonban, hogy a téma kimeríthe- 
tetlen, és ezúttal igyekszem mélyebben belemenni egyes 
részletekbe, illetve megpróbálom áthelyezni a hangsúlyt az 
objektumorientált szemléletmódra, annak szükségességére. 
Most nem egy konkrét problémát mutatok be (mint annak 
idején a biliárdjátékoy, hanem kisebb, de lényegretörőbb 
példákon keresztül igyekszem szemléltetni az egyes elemek 
jelentőségét. 


Egy UML modell alapvetően kétféle elemből állhat: egyrészt 
szöveges, másrészt vizuális részekből. Az előzőekre jó példa 
a különböző használati esetek felsorolása, leírása, az utóbbira 
jónéhány példadiagramot felsorakoztattam a korábbiakban. 

Az objektumorientált világban elengedhetetlen az osztályok- 
ban történő gondolkodás, így először is járjuk körbe ezt a kér- 
déskört. Mint azt már korábban többször kifejtettem, az osztá- 
lyok az emberi gondolkodást igyekeznek tükrözni, így első rá- 
nézésre értelmetlennek tűnhet nagy hangsúlyt fektetni rájuk. 
sHa olyan közel áll a gondolkodásomhoz, minek annyit gon- 
dolkodni rajta?" — merülhet fel a kérdés. Itt most valóban nem 
pszichológiai fejtegetésekről lesz szó. Azt igyekezzük felderí- 


teni, hogy az intuitíven meghatározott osztályok ho- 
gyan közelíthetők az optimális megoldáshoz, azaz 
ahhoz, ahogyan a leghatékonyabban leképezhetjük 
azt egy szoftverben. 

A hatékonyság itt nemcsak azt jelenti, hogy a szoft- 
ver működése a lehető leggyorsabb legyen. Magával a kóddal 
szemben is támasztunk különböző követelményeket: könnyen 
olvasható, érthető, áttekinthető legyen, hiszen bármikor szük- 
ség lehet arra, hogy átadjuk azt egy másik kollégának, és egy 
idő után a saját kódunkban sem tudunk eligazodni, ha nem 
követjük ezeket az irányelveket. 

Másik elvárás az, hogy a program könnyen módosítható, bő- 
víthető legyen, azaz fel legyen készítve újabb modulok hoz- 
záadására, illetve ha a meglévő modulokat módosítani kell, 
ne kelljen újraírni az egész rendszert, hanem a lehető legki- 
sebb erőfeszítéssel ezt megtehessük. 

Ehhez azonban jól átgondolt struktúrára, jól kialakított osztá- 
lyokra van szükség. 

Lássuk tehát, hogyan írhatunk le egy osztálystruktúrát. Termé- 
szetes módon adódik, hogy alapvető elemei az osztályok, 
amelyek között különféle kapcsolatokat definiálhatunk. Erre 
különféle eszközök állnak rendelkezésünkre. A két legismer- 
tebb a Microsoft Visio (amelyet én magam is használni fogok 
az elkövetkezőkben), és a Rational Rose (talán nem meglepő, 
hogy a Rational rendelkezik ilyen eszközzel...). 

Ha a Visiot elindítjuk, egy menüben választhatjuk ki, milyen 
célra szeretnénk aktuálisan használni. Válasszuk a Software 
csoportból az , UML Model Diagram" opciót. Ekkor a megnyí- 
ló ablakunk három részből áll: középen látható maga az UML 
modell, ami első indításkor természetesen üres, később töltjük 
fel tartalommal. Bal oldalon találjuk az egyes UML elemek fel- 
sorolását, amelyeket hozzáadhatunk modellünkhöz: 


Use Case 
Static Structure 
Statechart 
Seguence 
Deployment 
Component 
Collaboration 
Activity 


BEBB8BBBBB 


Lássuk, mit is jelentenek ezek az elemek: 
A Use Case: Használati esetek diagramjai definiálhatók. 
Az esetek többségében szükség van ezek szöveges 
leírására is. Később látunk rá példát. 

AA Static Structure: A rendszer statikus osztálystruktúráját 

írhatjuk le segítségével. 

A Statechart: Az állapotátmenet-diagram rajzolásához ad 

eszközöket. 

A Seguence: Különböző szekvenciadiagramok rajzolá- 

sára. 

A Deployment: A rendszer telepítésével, fizikai felépíté- 
sével kapcsolatos információk meghatározására. 
Component: A rendszer komponenseit rögzíthetjük. 
Collaboration: Együttműködési diagramok rajzolására. 
Activity: Akciódiagramokat definiálhatunk (később 
ezekre is látunk példát). 


88688 


Láthatjuk, hogy egy UML modell igen összetett is lehet. Per- 
sze a megismerés útján elindulva nem zúdul a nyakunkba 
rögtön az összes UML diagram, ezek fokozatos elsajátítása 


adi 
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E sokkal hasznosabb lehet — persze ha közben tisztá- 
t(— ban vagyunk azzal, hogy teljesértékű modellt csakis 
ezek együttes használatával kaphatunk. 
A fokozatosság elvét követve tehát térjünk rá az osz- 
tálydiagramokra, azaz a rendszer statikus struktúrá- 
jára. A ddagramok megrajzolásához első lépésben azonosítani 
kell az adott problémát leíró osztályokat és ezek kapcsolatait. 
Első megközelítésben intuitív módon igyekszünk felvázolni a 
megoldást, vagyis azonosítjuk a rendszer egyes különálló mo- 
duljait, ezek felelősségét, és a közöttük fennálló kapcsolato- 
kat. Például egy vállalati szoftver esetében szükség lehet 
számlázó, raktárkészlet-nyilvántartó, megrendelés-kezelő, 
adóbevallás-készítő, és egyéb modulokra. Ezek mindegyiké- 
nek jól meghatározott feladata van, ezt részletesen kifejthetjük 
már a tervezés kezdeti szakaszában is. 
Például: 


Számlázómodul: 

Feladata a különböző számlák kiállítása és nyom- 
tatása. A számlán szerepelnie kell az aktuális 
jogszabályoknak eleget tevő adatoknak (lásd ÁFA- 
törvény X-edik paragrafus), valamint az eladáshoz 
kapcsolódó termékek illetve szolgáltatások 
mennyiségének, ÁFA-tartalmának, egységárának és 
együttes értékének. 

A felhasználó egy űrlap kitöltésével állíthat ki 
újabb számlát. A számlán szereplő tételek mind 
egyedi azonosítóval ellátott termékek és szolgál- 
tatások, melyeket egy külön erre a célra összeál- 
lított felületen vihetünk be a rendszerbe. 

A számla nyomtatása a bevitt adatok alapján auto- 
matikusan történik a jóváhagyással egyidőben. 

A nyomtatásnál fontos kritérium, hogy többoldalas 
számla esetében mindegyik lapon szerepelnie kell 
a fejlécnek, ami tartalmazza az eladó és a vevő 
adatait, valamit az aktuális dátumot és a számla 
sorszámát, 


Előírhatunk olyan követelményeket is, amelyek az egyes mo- 
dulok közötti kapcsolatokat határozzák meg: 


A számlákon csak és kizárólag olyan termék szere- 
pelhet, amiből kellő mennyiség áll rendelkezésre 
a raktáron. A számla kiállításával a raktáron 
lévő mennyiség a számlán szereplő mértékben 
csökken. . K 


Így egy olyan rendszerváz áll rendelkezésünkre, amely alap- 
ján már elkezdődhet a konkrét megvalósítás tervezése. Hang- 
súlyozom, hogy ez a fázis még a megrendelő bevonásával tör- 
ténik, hiszen az ő intenzív közreműködése szükséges a rend- 
szer alapkövetelményeinek meghatározásához. 

Az osztályhierarchia meghatározásához alapul ezeket a fent 
meghatározott komponenseket használjuk, majd ezt a modellt 
finomítjuk. A számlázásnál maradva abból indulunk ki, hogy 
szükségünk lesz erre a modulra. Az előbb vázolt követelmé- 
nyekből már látszik is, hogy a számlázás több alfeladatból áll: 
számla kitöltése, tárolása, nyomtatása, stb. Vajon milyen osz- 
tályok valósítják meg ezeket a feladatokat, van-e szükség kü- 
lön osztályokra minden egyes feladatkörhöz? 

Első megközelítésben persze kiindulhatunk abból, hogy 
egyetlen osztály felel majd a számlázásért, s ennek lesznek 





különböző metódusai, amelyek a nyomtatást, tárolást, stb. 
végzik. 

Jogosan merül fel az igény, hogy ha már osztályokról beszé- 
lünk, lássunk is egyet, ábrázoljuk, lássuk el különböző jellem- 
zőkkel stb. Ám legyen. 

Az osztály szimbóluma UML-ben egy téglalap, amelyet há- 
rom részre osztunk az alábbiak szerint: 


ElsőOsztályom 


attribútum 





metódus 


E Osztály ábrázolása UML-ben 


Az ábra egyes részei: 
1. Az osztály neve 
2. Az osztály attribútumainak listája 
3. Az osztály metódusainak listája 


Érdekességként említem meg, hogy az UML elődeiként élő 
egyes módszertanok más és más szimbólumokat használtak 
az osztályok jelölésére. Persze az osztályfogalom is eltért töb- 
bé-kevésbé az UML-ben használatostól. Néhány példa: 





ElsőOsztályom 


ElsőOsztályom 





Egy osztály ábrázolása az OMT és a Booch-féle szim- 
bólumrendszerben 


Az osztályt a neve egyértelműen azonosítja. Különböző meg- 
valósításokban különbözőek az elnevezési tradíciók, ráadá- 
sul ezek cégenként, projektenként is eltérhetnek. Lehet, hogy 
az osztályneveket névterekbe soroljuk, ekkor az osztály a 
névtér:osztálynév páros határozza meg. Lehet, hogy a tradi- 
cionális nevezéktan azt írja elő, hogy valamilyen előtagot te- 
gyünk az osztályunk neve elé (például classMyFirstClass). 
Szokás az osztály nevében szereplő szavakat nagybetűvel 
kezdeni a könnyebb olvashatóság kedvéért. Általánosan is el- 
mondható, hogy egy cégen illetve projekten belül célszerű 
egyfajta nevezéktant kialakítani, amelynek betartása minden- 
kire egyaránt kötelező. Így kommunikálni és együtt dolgozni 
is sokkal egyszerűbb, hatékonyabb, hiszen elkerülhetjük pél- 
dául azokat a szituációkat, amikor egy osztályt BélaOsztálya 
névvel illetnek az éles rendszerben (ne tessék nevetni, talál- 
koztam már ilyennel). 

Persze ezek az észrevételek nemcsak az osztályokra érvé- 
nyesek... 


Az osztályok következő fontos tényezői az attribútumok. 
Ezek az adattagok az osztály működéséhez szükséges válto- 
zók, szerepük különböző lehet. Elképzelhető, hogy az osz- 
tály belső működéséhez, , életéhez" szükséges egy új változó 
bevezetése, ekkor felesleges azt kifelé is publikálni. Lehet, 
hogy az adott változó a külvilág számára is hordoz informá- 
ciókat, ekkor láthatóvá kell tenni. Olyan eset is elképzelhető, 
amikor az elrejtés nem járható út, mert az osztályból leszár- 
mazó egyéb osztályoknak szüksége van az adott változóra (a 
származtatásra és az öröklődésre később részletesen kitérek), 
viszont teljesen publikussá sem szeretnénk tenni. Természe- 
tesen ez is megoldható, pontos menetét később bemutatom. 
Előtte azonban lássuk az osztályok metódusait. Ezek azok a 
cselekvések, amire az osztály egy példánya képes. Ide tarto- 
zik az adott példány születése, megszűnése, és egyéb speci- 
fikus dolgok. A metódusokra is értelmezettek a fenti látható- 
sági feltételek, azaz itt is meghatározhatjuk, ki számára sze- 
retnénk elérhetővé tenni ezeket. 

Általános alapelv, hogy mindent a lehető legszűkebb körben 
tegyünk láthatóvá, vagyis aki elől csak tudjuk, rejtsük el. En- 
nek ára lehet, hogy például az attribútumokat privát haszná- 
latúvá tesszük, de definiálunk hozzájuk elérő metódusokat: 
egyet a kiolvasására, egyet a beállítására (amennyiben a logi- 
"ka szerint ez kívülről közvetlenül lehetséges). 

Miért jó mindez? Képzeljük el azt a szélsőséges esetet, ami- 
kor minden attribútum (szokásos még a paraméter elnevezés 
is) és minden metódus elérhető mindenki számára. A többi 
osztályban létrehozzuk az adott osztály egy példányát, majd 
ha úgy gondoljuk, hogy valamely tagváltozójának értéke nem 
felel meg számunkra, rögtön nekiesünk, és már át is állítjuk 
azt, függetlenül attól, hogy logikailag esetleg ez nem megen- 
gedett, mert csak az osztály belsejében, egyéb paraméterek 
alapján történhetne értékadás. 

Másik bökkenő, ha módosul az osztályunk felépítése: átne- 
vezzük az adott tagváltozót, vagy egy újabb algoritmus hasz- 
nálatával igyekszünk hatékonyabbá tenni egy-egy metódust. 
Ha minden mindenki számára elérhető, és a fent bemutatott 
módon, közvetlenül használunk mindent, millió helyen 
kényszerülhetünk átírni az alkalmazásunkat, mert nincs egy 
olyan egységes interfésze az osztályunknak, amely elfedné 
ezeket a belső dolgokat. 

Lássunk egy példát erre is. Legyen adott egy olyan osztály, 
amely — múlt havi példámnál maradva - torták elkészítéséért 
felelős. A Torta osztály felépítése most némileg eltér a koráb- 
bitól: 


-előkészítésildő : int 
-axpihentetésildő : int 
-rsütésildő : int 
-krémkKeverésildő : int 
-összeállításildő : int 
-:szaummakElkészítésildő : int 
-:szummaildőSzámítás : int 


S A Torta osztály 


Jól látható, hogy az osztálynak több idő-paramétere is van. 
Feltételezzük, hogy a szummatlkészítési idő az egyes idők 
összege, hiszen mondjuk egyetlen személy sürgölődik a kony- 
hában, így nem párhuzamosíthatók a tevékenységek. Ezért lét- 


rehozunk egy szummaldőSzámítás() nevű metódust, amely- 
nek belseje valahogy így néz ki: 


public int előkészítésiidő; 
public int pihentetésildő; 
public int sütésildő; 

public int krémKeverésildő; 
public int összeállításildő; 
public int szummaElkészítésildő; 


public int szummaldőSzámítás() 
€ 
szummaElkészítésilidő - előkészítésildő 4 
pihentetésildő 4 
sütésildő 4 
krémKeverésildő 4 
összeállításiIidő; 
return szummaElkészítésiIidő; 


Ez mind szép és jó, működik is, van azonban egy apró bökke- 
nő. Mi van akkor, ha a felhasználó az osztály példányosítása- 
kor (vagyis amikor konkrét objektumot hoz létre belőle) nem 
veszi figyelembe ezt, és a szummatElkészítési időnek is közvet- 
lenül szeretne értéket adni? Valahogy így: 


[1] Torta dobostorta - new Torta(); 


[21 
[3] dobostorta.előkészítésildő - 25; 
[4] dobostorta.pihentetésildő - 20; 
[51 dobostorta.sütésildő - 25; 
[61 dobostorta.krémKeverésildő - 35; 
[71 dobostorta.összeállításildő - 35; 
[8] 
[91 cConsole.Write( 

dobostorta . szummaldőSzámít ( ) ) ; 
[10] 


[11] dobostorta.szummaElkészítésilidő- 10; 


Az első sorban létrehozunk tehát egy példányt a Torta osztály- 
ból. Ezt a példányt (objektumot) dobostortának hívják. Beállít- 
juk az egyes részfázisokhoz tartozó időtartamokat, majd 
kiíratjuk a szummaldőSzámít( metódus eredményét. A fenti 
adatokkal ez 25--20--25--35--35 -— 140 perc. 

A 11. sorban azonban valami miatt a kezünkbe vesszük az irá- 
nyítást, és az elkészítési időt 10 percre állítjuk. A következő 
használatkor (lekérdezéskor) valószínűleg jó alaposan megle- 
pődünk majd, és fellelkesülünk, hiszen az itt szereplő adatok 
szerint egy dobostorta elkészítésére elegendő 10 perc úgy, 
hogy mindössze egyetlen ember van a konyhában — úgyhogy 
ezzel a felkiáltással sietve rávesszük lelkes Párunkat, hogy süs- 
sön nekünk tortát, mi meg közben ellazulva nézhetjük ked- 
venc meccsünket a TV-ben. Az eredmény valószínűleg nem 
dobostorta, hanem kétségbeesett siránkozás lenne, hogy ez 
már megint nem működik, hiszen 10 perc alatt még az előké- 
születek sincsenek készen a konyhában. k 

A problémát orvosolandó, tegyük rejtetté a szummaElké- 
szítésildő attribútumot, hogy kívülről ne legyen közvetlenül 
hozzáférhető. Ha ezután a dobostorta attribútumait nézzük, 
azt láthatjuk, hogy ez eltűnt a kívülről látható elemek listájá- 
ból. Mindössze a szummaldőSzámítás() metódussal férhetünk 
hozzá az éppen aktuális értékhez. 
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lehet hasznos a használata ahelyett, hogy minden 


hosszának összeadásával? Valahogy így: 





A 9. sor itt ugyanazt az eredményt adja, mint a 
szummaldőSzámítás függvény, miért kell akkor még ezzel is 
növelni az osztály méretét? 

Gondolkodjunk ismét közösen. Képzeljük el a következő szi- 
tuációt: a programot felhasználó Gizike ránk szól, hogy neki 
nagyon hiányzik még egy kikeverésildő attribútum is, mert ezt 
igazából nem tudja sem az előkészítéshez, sem a pihentetés- 
hez, sem a sütéshez sorolni. Felvesszük hát az osztályba ezt 
az új attribútumot, sőt még inicializálunk is egy értéket neki 
(mondjuk 0-ra), hogy a már korábban leprogramozott és létre- 
hozott objektumoknál se legyen gond az értelmezése. Igen 
ám, de Gizike elkezdi beállítani ezeket az értékeket, mondjuk 
a dobostortára 30 percet. Néhány óra vagy nap múlva ismét 
sikítva hív bennünket, hogy valami nem jó, mert ezek az érté- 
kek nem adódnak hozzá a teljes elkészítési időhöz. Kényte- 
len-kelletlen nekiállunk orvosolni ezt is, és fél óra után 
leimádkozzuk a csillagokat is az égről, hiszen minden egyes 
összegszámítást át kell írnunk, pontosabban kibővíteni az új 
időtartammal: 





Milyen előnye van még ennek a metódusnak? Miért 


egyes meghívását kiváltanánk az egyes időszeletek 


A 9. sorhoz tehát újabb tagot adunk. És ugyanezt megtesszük 
a többi háromezer helyen is, ahol az adott összegre vagyunk 
kíváncsiak. Mennyivel egyszerűbb lett volna megvalósítani a 
szummaldőSzámítás függvényt, és azt meghívni ezeken a he- 
lyeken! Hiszen akkor egyes egyedül a függvény belsejét kelle- 
ne most átírnunk, csak ott kellene felvennünk az újabb tagot 
az összegbe, és akkor mindenhol helyesen jelenne meg az ér- 
ték! 

Hasonló a helyzet akkor is, ha rájövünk, hogy egy tagváltozó 
neve nem felel meg a tartalomnak (például időközben ponto- 
sítottuk a felhasználó igényeit), vagy a tagváltozóban egyéb 
módosításokat kívánunk bevezetni. Ha az attribútum közvet- 
lenül elérhető kívülről is, a belső módosítás után mindene 
egyes hivatkozást át kell írnunk. Ha azonban a fentihez ha- 
sonlóan minden paraméterhez van külön elérőfüggvény, ez a 
veszély nem áll fenn, hiszen ekkor elég a függvényt módosí- 
tani, kifelé transzparens lehet a változás. 


Jelenleg tehát már értjük, mik azok az osztályok, milyen ada- 
tokat kell megadnunk definiálásukkor. Semmit nem tudunk 
azonban még az osztályok kapcsolatáról, és egy csomó olyan 
gyakorlati dologról, ami szintén hasznos lehetne munkánk- 
hoz. Ezért a következő hónapokban tovább boncolgatom ezt 
a témát: részletezem az osztályhierarchiák felépítésének mód- 
jait, a különböző osztályok együttműködését. Bemutatom az 
UML-hez tartozó többi diagramot is, és azok kapcsolatait egy- 
mással, hogy világossá váljon, hogyan épül el egy rendszer 
teljes UML modellje. 

Addig is mindenkinek jó szórakozást kívánok az UML-lel és a 
hozzá kapcsolódó CASE eszközökkel történő ismerkedéshez! 
Egy dolgot nem szabad elfelejteni: tanulni csak úgy lehetsé- 
ges, ha az ember próbálkozik! 

Úgyhogy hajrá! 


Molnár Ágnes 
agnes.molnarOvipmail.hu 
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MCSE (rendszermérnök) képzés 
az öt kötelező vizsgához 
430.000 helyett már nettó 399.000 Ft-tól!!! 


Nagy, összetett informatikai rendszereket és hálóza- 
tokat üzemeltető szakemberek képzése, akiknek fela- 
datuk lesz Windows 2000 alapú hálózatok teljeskörű 
adminisztrálása és támogatása, informatikai infra- 
struktúrák tervezése. 


Szeptember 15-től! 


MCSA (adminisztrátor) képzés 
a kötelező vizsgákhoz 
270.000 Ft helyett már nettó 229.000 Ft-tól! 


A kisebb informatikai rendszereket és hálózatokat 
üzemeltető szakemberek számára ajánljuk, akiknek 
feladatuk lesz Windows 2000 alapú hálózatok telepí- 
tése, konfigurálása, adminisztrálása, karbantartása. 


Szeptember 15-től! 


A képzéseken a Windows Server 2003-as rendszerek újdonságairól is szó esik. 
Igény esetén a sorozat után kedvezményes Windows Server 2003 átképzést is igénybe vehet! 


MCDBA (adatbázis-adminisztrátor) képzés 
a kötelező vizsgákhoz 
504.000 Ft helyett már nettó 459.000 Ft-tól! 
Microsoft SOL 2000 alapú adatbázisrendszerek tel- 
jeskörű üzemeltetésével, támogatásával, karbantar- 
tásával, tervezésével és implementálásával megbí- 
zott szakemberek részére ajánlott képzés. 


Szeptember 15-től! 


Microsoft .NET fejlesztői képzés 
774.000 Ft helyett nettó 619.000 Ft-ért! 


Fejlesztők, programozók számára ajánlott képzés, 
akiknek feladatuk lesz összetett, Windows-alapú és 
webes alkalmazások készítése, fejlesztése, szolgálta- 
tások implementálása és tervezése. Az alapoktól a 
haladó szintig, párhuzamosan a Ct és Visual 
Basic .NET programnyelveken. 


Október 13-tól! 


Válassza ki az Önnek megfelelő minősítést és képzési konstrukciót! 


Hivatalos Microsoft tanfolyamokra épülő, rugalmas beosztású, kedvezményes konst- 
rukciójú és árú képzéssorozatok. Különböző segédanyagokat, vizsgafelkészítő anya- 
gokat tartalmazó oktatási konstrukciók és csomagok. Kedvezményes lehetősé- 

gek a szabadon választható vizsgára felkészítő tanfolyamokra. 


A megadott árak a 259-os ÁFÁ-t nem tartalmazzák. 


Microsoft 
CERTIFIED 


Technical 
Center 


rele Zoe to ve 1olaio) 


(Simon Ferenc) www.szamalk.hu/tisza 1115 Budapest, Etele út 68. 


S 
f a X 
SZÁMALK TOÓT 


Education 
ti 









